ISFDB:Community Portal/Archive/Archive15

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

new header templates

I have recently created Template:AuthorHeader and Template:PubHeader, to provide standardized headers for Author: and Publication: pages in the wiki. We already have Template:BioHeader and Template:PublisherHeader. Thes tempaltes can, with a small code change, be used to put the standard header in by defualt when an editor clicks on the wiki-link for a DB page to a previously empty wiki page. They can also be added in bulk to existing pages in the appropriate namespaces.

Does anyone have any comments or objections about making use of these header tempaltes standard in the pages in the Author:, Publication:, Bio: and (perhaps) Publisher: namespaces. (It may be that the publisher one should wait until there has been more progress on publisher standardization. In fact I think it probably should.) -DES ^Talk 22:43, 13 June 2009 (UTC)

There is probably nothing wrong with a generic publisher header that only puts it in the publisher category. That way we can (if we choose) impliment all new links to the wiki from the database at the same time, and later if/when we think it prudent the header itself can be adjusted here in the wiki, and no code update to the isfdb itself is required. Kevin 22:52, 13 June 2009 (UTC)

Hmm perhaps. except that for links to work, {{PublisherHeader}} requires a numeric ID parameter, to link to the proper ISFDB publisher record. Adding a generic template without such a parameter would be pointless (and i don't see much value to a huge category simply including all publisher pages anyway: the same list is available via special:allpages). If we setup pages with record numbers specified, and publisher merges are done later, the wiki pages will need to be changed at the same time. of course, requiring merging editors to update the wiki also might be one more way to slow down publisher merges. :) Adding the publisher header is not a horrid idea, if we are prepared to update pages when publishers are merged. If we are not, then it should probably wait. -DES ^Talk 23:06, 13 June 2009 (UTC)

The way the preload function works, the text to be preloaded is in the wiki on [Publisher:Whatever_I_Call_The_Template_Page] so today I can write the code to preload the template page (With just the publisher category, the publisherheader template, or nothing at all), and 6 months, 6 years from now the page in the wiki is all that needs to be edited to change text preloaded. Kevin 00:15, 14 June 2009 (UTC)

That works for me. -DES ^Talk 00:27, 14 June 2009 (UTC)

Note: that reminds me we should probably protect those preload pages when we make them. Just a semi-random non-linear thought. Kevin 00:37, 14 June 2009 (UTC)

Any comments on the other three header templates? -DES ^Talk 23:08, 13 June 2009 (UTC)

The other templates all look fine (shrug) - Things like that I usually don't notice that something bothers me until I'm using it in action. But again, both the template and the preload can be modified without a code update. Kevin 00:36, 14 June 2009 (UTC)

True. However I am considering using AWB to more or less mass-populate the existing pages with the headers, and if you or anyone had strong objections i would want to know. Of course the template can always be edited later to change the results en mass. -DES ^Talk 01:02, 14 June 2009 (UTC)

I think the ones that don't need an input variable should be fine to deploy that way. If anyone has a problem with the template, itself, that can be changed on the template page. Kevin 01:57, 14 June 2009 (UTC)

Patch r2009-03

Patch r2009-03 has been tested and is ready to be installed on the live server on Sunday. The following changes will be implemented:

• Bug 2796509. URLs not linked correctly in the post-approval screen.
• Feature 2800631. (was Feature:90126 here) Links to Submitter and Holder's talk pages
• Feature 1969512. Image Preview on Pub updates
• Feature 2800669. (Part of Feature 90147 here) Make getting from Pub Delete Submission to Pub easier
• Feature 2800680. (Was Feature 90110 here) Have the HOLD screen link to new-submissions
• Feature 2801298. (Was Feature 90109 here) Add Links to child VTs
• Feature 2800716. Add parent series to series display.
• Feature 2804561. (partial implementation). Add variant titles to series display
• Feature 2802553. Link to view pub after verify
• Bug 2802728. 8888/9999 still appearing in Series and Diff Publications
• Bug 2802844. Do not display "Other Sites" nav section for non-ISBNs
• Features 2802730 and 2799105. Provide link to ISFDB Hosted Image Wiki Page & Provide updated Cover Art Supplied by Links

Please report any issues with the patch here. Also, please note that the way Talk pages are linked on the main Moderator screen is experimental and may be changed based on moderator feedback. Ahasuerus 04:13, 14 June 2009 (UTC)

Patch installed, test away! Ahasuerus 16:43, 14 June 2009 (UTC)

Well, it looks to have installed correctly to me. I'd forgotten how subtle some of the changes are. Liking the series changes, but I see Mike is working on some of the Dray Prescot, which should be a real test! BLongley 22:00, 14 June 2009 (UTC)

Man I LOVE those variant links! Kevin 03:25, 15 June 2009 (UTC)

After being away for three days, and looking at the list of projects planned above, my mind is in a whirl, trying to take it all in. (Starting Saturday I'll be gone for a week, so I can't imagine how different things will be by the end of the month!) Is there one page where all of the changes can be highlighted, written out in English without resorting to the numbers (as in the listing beginning this topic), and explaining the changes to poor non-technie souls like me? Thanks. MHHutchins 20:46, 15 June 2009 (UTC)

Fear not, Michael, it's not nearly as bad as it looks! (Well, OK, perhaps editing the Community Portal page 92 times in one day was a bit excessive :-) The bug/feature numbers listed above refer to their descriptions on Sourceforge (bugs, features). The discussion above mostly covers big ticket items like increasing the number of supported Title Types (Novel, Essay, Editor, etc), which are not likely to be implemented overnight. Now that we have proved that we can make small changes successfully, we are trying to figure out what kinds of major changes we want to implement down the road so that (a) we could prioritize them and (b) avoid collisions and conceptual mismatches. We wouldn't want developers improving an area of the application which will be completely replaced 3 patches later :) Ahasuerus 00:53, 16 June 2009 (UTC)

Michael, don't worry about coming back to find the whole ISFDB changed beyond comprehension! Most of the actual changes lined up are still pretty small, and I'm trying to get us to go for "medium" next. And suggesting steps toward major changes. But it's good to share our dreams while there's still some enthusiasm. (Which will probably drop as soon as we introduce something the developers and testers liked that everybody else doesn't like.) I see the comment "the way Talk pages are linked on the main Moderator screen is experimental" hasn't invited a "hate that, remove it at once!" yet though, so some of us seem to be a bit more nervous than we ought to be. Just keep us in check - if we didn't break something in r2009-03, we might in r2009-04. So point out problems as soon as you see them. BLongley 22:29, 16 June 2009 (UTC)

In fact, I like it and want the same link on the approval screen, indeed I think i would be more likely to use it there than anywhere. -DES ^Talk 22:50, 16 June 2009 (UTC)

Linking to Talk pages is definitely useful, but displaying two links per table column means that the text now wraps (at least on some screens) in cases when it used not to. Perhaps we could eliminate the link to the User page if the Talk page link is sufficient? Ahasuerus 23:30, 16 June 2009 (UTC)

Looking at it again now it's live, losing the outer set of brackets for the "(Holder ((Talk))" might look better and would save two characters. (I know, I'm criticising my own code changes, I can wear two hats.) BLongley 19:08, 17 June 2009 (UTC)

That would be fine with me. But the link would need to have the userID as the link text, to identify the submitter. One moment though: a red-link on the userID often indicates a relative newcomer, so it has some value. On the approval screen the name is on its own line, so having both links shouldn't present a problem, IMO. -DES ^Talk 23:38, 16 June 2009 (UTC)

Should be simple enough. Is there a feature request number for that? BLongley 19:08, 17 June 2009 (UTC)

FR# 2807731 (Link to submitter's talk page from approval screen). Thanks. -DES ^Talk 19:37, 17 June 2009 (UTC)

I did a test and it does cause a couple columns to wrap at 800x600 and 1024x768. That said, I think at 4% to 8% we can stop coding for 800x600 as a general practice and 1024 screenwidth is pretty much on the way out. I wouldn't argue against coding for an assumed screen width of 1280 from 1280x1024, the next general size up from 1024, and still hit ~50% of everyone and growing. Kevin 00:49, 17 June 2009 (UTC)

Well, I for one use 800x600, Kevin. Too much eyestrain at 1024x768. (There are a couple of web sites I have to switch for because screens don't scroll to where I can click on needed links, & it's a real PITA.) -- Dave (davecat) 12:13, 19 June 2009 (UTC)

I haven't really been considering screen widths exactly, but try not to widen unnecessarily. I think there was a feature request to show a bit more of the subject (it's truncated at 40 characters at the moment) and some guidelines would be good for what people can cope with. (Which does bring in the question of whether the mod screens can have different limits to the others - part of me says "don't be elitist", but practically, it might be worth checking what works best for each type of user.) BLongley 19:08, 17 June 2009 (UTC)

And before we assume a minimum size based on our desktop/laptop displays, is there any sign of people using the site via iPhones or Googlephones or other Smartphones? We might have to consider smaller displays. (I'm willing to test such, if somebody feels like donating such a mobile and paying the data charges!) BLongley 19:08, 17 June 2009 (UTC)

I'm happy to consider smaller screens for 'users' of the database, but Editors, and Moderators? Not really. I personally use the database from my phone several times a year when I'm on a book buying tear, or digging through stacks sometimes. My only complaint from a 'user' perspective is that the ISFDB Index card icon, keeps the menu frame from shrinking, causing all the biblio stuff to roll horrendously as that frame can be shrunk. This could be fixed by putting a 240 pix wide blank gif at the top of the biblio frame in display, which will prevent the biblio frame from attempting to collapse beyond that point. That will be sufficient to allow a cell phone user to put that frame center screen and make maximum use of the database and limited screen real estate 'on the go'. Kevin 00:45, 18 June 2009 (UTC)

As a self-confessed "phone user" of the database, you get to enter the feature request :) Ahasuerus 01:12, 18 June 2009 (UTC)

Splitting Authors and Artists

This section split out of #Roles above, due to topic drift. -DES ^Talk 23:32, 17 June 2009 (UTC) One thing I would like people to consider is whether we should be separating "Authors" from "Artists" and all the other roles. I do find myself annoyed when looking for an artist that may match a signature, or an author that may be a pseudonym, and get either type of search cluttered with the other type. I think this may only get worse when we add Collection Editors and Translators and Readers and Designers and Photographers, etc. (In fact, I know they were already making things worse, I've spent a lot of time demoting "stray authors" to pub notes in the meantime.) BLongley 19:29, 16 June 2009 (UTC)

As to separating Artists from Authors, that has been raised before, but should be discussed. I haven't found it a major problem, and we would need to handle the cases where an individual is both. Not the most common case, but far from unheard of, and includes some very well-known individuals. (This may be more common with self-published work where the author also does the cover.) Hmm... What if we add a flag, or rather a set of flags, for "author", "artist", "editor" and the like, to each "person" record. Then a search could restrict to only records with the "artist" flag set, or be done for all "people" as the user might prefer. Just a thought. -DES ^Talk 19:55, 16 June 2009 (UTC)

There are indeed multi-talented "Authors" here and if we do split I think we have to start with assuming that they are the same person: e.g Terry Pratchett, Clive Barker and Robert Rankin certainly are both writers and artists. But Mel Odom and Mel Odom (artist) (not sure why I can't link to that one) aren't, as far as I know, and keep getting confused, hence the desire to split them without the need for suffixes. BLongley 20:57, 16 June 2009 (UTC)

{{A}} has a problem with "author" names that include parens, or some other non-alphanumeric characters. In those (fairly rare, I hope) cases you need to link like this: {{A|Mel Odom (artist)|altName=Mel_Odom_(artist)}} gives Mel Odom (artist). See Template:A/doc#Special case for more detail.

I see you point about possible confusion. But there are certainly cases of two or more authors with the same name, so such a split would at best reduce, not eliminate, the need for disambiguation. (It might also require changes to the isfdb name template on Wikipedia, which has been used to link artists as well as authors to their ISFDB pages.) And what would we do if Mel Odom (artist) decided to write and publish a book? Still a split would have some advantages. -DES ^Talk 21:25, 16 June 2009 (UTC)

Other examples of people with both art and writing credit here:

• William Pene du Bois
• Mervyn Peake
• J. R. R. Tolkien
• Richard Powers
• Tim Kirk
• Wendy Froud
• Terri Windling
• Jack Davis
• Katherine Coville
• Cat Sparks
• Mark Wheatley
• James Warhola
• Virgil Finlay
• P. C. Hodgell
• Yoshitaka Amano
• Laura J. Underwood
• Quentin Blake
• Dave McKean
• Barbara Kiwak
• Bob Eggleton
• Jason Van Hollander
• Richard Pini
• Wendy Pini

And all those (except for the first 3 and last 2 who were off my head) were derived from a single page of advanced search (looking for cover art on titles with "Tale"), and i ignored artists with only non-fiction and essay credits. If that search was representative, at least 15% of cover artists here have at least one fiction credit here also. -DES ^Talk 22:01, 16 June 2009 (UTC)

A quick scan says we have (of the last backup I've loaded) 55K different title authors, of which 12k have COVERART or INTERIORART. So even if a sixth of the artists have fiction as well, we can probably move 10K "Authors" to pure "Artist". Given the current worries about some search performances, there may be some noticeable performance benefits from such. A small improvement in searches for Fiction authors probably, but a big improvement in Cover or Interior artist searches. BLongley 18:44, 17 June 2009 (UTC)

Interesting. But if 10k authors are moved to an "artist" table, and 2k stay in the main "author" table, wuldn't a search for a cover artist have to check both tables, as there would be no way to know if a given artist was in the 20k or the 2k? Wouldn't that actually hurt performance? or am i missing something? Also, would a "pure artist" be moved back to the author table when/if s/he publishes a work of fiction (SF that is)? How would that work. I am not trying to pick holes for the sake of being contrary; I just see complications. I agree that the large majority of our authors have no publications of art in the db, and that a fair majority of our artists have no fiction pubs, and we ought to be able to take advantage of that fact. But I don't quite see how without making lots of problems in the minority cases. -DES ^Talk 19:21, 17 June 2009 (UTC)

2K authors would be in both, with some sort of link. If you're only searching for artwork, you'd look at the Artists table and look at 12K Artists. If you're looking for fiction or essays, you'd look at 45k Authors. 55K to 45K is a small improvement on Author searches, searching 12K Artists is far better than searching 55K "Authors" for Artists than now though. BLongley 23:05, 17 June 2009 (UTC)

End section split out of #Roles above -DES ^Talk 23:32, 17 June 2009 (UTC)

That makes sense, the only renaming problem is making sure that the link stays intact and that data is propagated to the other table as needed. Oh and copying a person from one table to the other as credits are added that require such. Doesn't look impossible at all, whether it is worth the effort i can't say. No futher objections form me. -DES ^Talk 23:37, 17 June 2009 (UTC)

Table? What? Copying? Why? What happened to DES's excellent suggestion of just flagging authors based on Roles? Then tailor the advanced search to limit Artist searches to Artist flagged 'Names', etc for all roles. You only need one Table, but it should/could be indexed against the flags. (Or am I confused as to the suggestion?) Kevin 00:30, 18 June 2009 (UTC)

I guess I forgot my own suggestion. That would surely be simpler to implement than a multi-table solution with non-normalized data. What the performance effect would be I can't say, but it might be worth trying. Whether it could also be used in basic searches (add an author and an artist search to "name" perhaps) I'm not sure -- not until it was stable anyway. -DES ^Talk 00:34, 18 June 2009 (UTC)

Seriously, folks, what's this nonsense about splitting artists from authors? What would be the purpose? What would be the benefits? Are we to expect an individual's efforts to be split into two summary pages? How many author/artists pages would benefit by splitting their work? Aren't the categories on the summary page sufficient to explain their roles for each publication? The whole business is a nonstarter for me. MHHutchins 04:39, 18 June 2009 (UTC)

Purpose: faster searches. Getting some of the broken Advanced Searches enabled (I believe the changes are mostly held up because of performance worries). It shouldn't affect any current displays, unless we want them to be affected. BLongley 18:57, 18 June 2009 (UTC)

If I understand DES' idea correctly, he is considering adding an extra flag to each author record which would tell the search engine whether the Author is responsible for art as well as for fiction. It wouldn't be that difficult to implement, but it seems to be more of a performance optimization issue rather than a design change that would affect our users. Adding "roles" that would support translators, editors of single author collections, etc would be much more consequential. Ahasuerus 04:47, 18 June 2009 (UTC)

Yes. This wasn't my idea initally and i wouldn't press for it to be a high priority -- it was Bill's idea. The objectives are two: to speed up searches, and to allow searches for an artist not to return similarly named authors who are not artists, so that the search results are more useful when it is known that an artist is being searched for (and, i suppsoe the other way about). This might well be availabe only under advanced search, although it could be part of Basic Searxh if we so choose. There would not, in any version of this idea, be separate bibiography pages for people who are both authors and artists, to the best of my understandign, and I would not support any such idea. -DES ^Talk 11:39, 18 June 2009 (UTC)

It's a fairly quick way to get some speed-up, and doesn't require tuning every possible advanced search query, which looks like becoming a nightmare. It also shouldn't change any current displays: you can just UNION the Writers and Artists tables (maybe via a view) back into Authors if you need the existing definition. Adding extra flags to each author record for Writer and Artist roles is simpler but needs more tuning to get the benefits - and would need revisiting for each new role. (Although we'd probably want to revisit in each case anyway, for instance when we add translator support do we want to add separate "Translations" sections to bibliographic pages?) The generic "define a new role and add it to the appropriate publications/titles/authors" is likely to introduce more tables that will reduce performance further and make advanced searches more complex. BLongley 18:57, 18 June 2009 (UTC)

Still, it doesn't have to be a genuine table split, a logical one might still help, I just don't know enough MySQL yet to be sure. In other DBMS I've used there are features like Bit-Mapped Indexes and Partitioning that would pretty much guarantee that "behind-the scenes" changes like adding an "Artist" flag would help even if the table stayed as one table. This is why I'm asking people to consider it - and at the moment it's probably a technical consideration alone, as I'm not proposing any screen changes to go with it. But such might naturally follow later - e.g. people are entering Companies and Photo Libraries for Coverart credits. Presumably the details for such would be a bit different from those of the (entirely human, as far as I know) Writers so it might be desirable to let Authors and Artists diverge to some extent - the common fields we already use can stay the same. BLongley 18:57, 18 June 2009 (UTC)

Duplicate entries on Summary bibliographies

We have long constructed the bibliography pages, particularly the summary biblios, on the principle that any given work will appear at most once on such a page (not counting variant titles and serializations). Novels which are part of a series appear in the series listing, not in the "Novels" section. (I vaguely recall that this was not true or not always true, for ISFDB1 pages, but i might be mistaken.)

I am coming to suspect that this is a mistake, at least in some cases. When a user visits a biblio page, particularly a fairly long one with multiple series and a good many non-series novels as well, looking for a particular novel that novel may be quite hard to find if the user doesn't know which series to look in. If, in addition, the user is not all that familiar with the way the ISFDB works, s/he may conclude that the novel isn't listed at all when s/he doesn't find it in the Novels section.

Now that short fiction series are listed on the biblio pages also, and short fiction works part of a series are not listed in the "Short Fiction" section, and may be in either the main "series" section above novels or the "short fiction series" section, depending on whether there are nay novels in the series, the problem is even more significant.

I do understand the desire to avoid redundancy, and the desire to avoid making already long pages even longer. But I think we may want to consider changing this display policy. I suggest two change options for consideration:

1. Fully redundant display. All works that are part of a series will always be displayed in the section where they would be if they were not part of a series, as well as in the relevant series section.
2. Optionally redundant display. A bibio could either display in the "fully redundant" mode described in #1, or as it does now. There would be some sort of user interface for switching between modes. Perhaps a logged-in user could set a preference for which display mode a biblio page defaults to when first entered. Perhaps the mode could be toggled separately for novels, short fiction, and other kinds of works.

Of course, we could make neither change. Such a change is not vital -- the alphabetic and chronological displays will let the work be found, once the user knows that. But I do think a "redundant summary" display might be useful (but it needs a better name if we go foreward). Does anyone else think thsi is worth considering further, before making a formal feature request, or even a design proposal? -DES ^Talk 23:27, 19 June 2009 (UTC)

Concur. And I think it should be deployed in two stages. First as a 'link' just as the alternate biblio pages are now. And then we should develop code to store user preferences. The 'Redundant' summary should be the default for all non-logged in users, and folks with no preference set. (As you mention, this is a tool to help those unfamiliar with the database find what they want, so it should be the default for those unfamiliar). So, to recap... Support as an alternate biblio for now, and later (if ever) the default once we can save preferences. Kevin 00:00, 20 June 2009 (UTC)

Of course it is not JUST a tool for newcomers. I suspect I would set my preference to redundant, if we had such a feature right now. -DES ^Talk 00:09, 20 June 2009 (UTC)

Another option would be a true, chronological list of titles, each tagged by type and annotated with series membership, without the groupings. --MartyD 01:56, 20 June 2009 (UTC)

That would be an option, yes. Personally I don't think I would want a list that intermixed novels, shortfiction, essays, etc, but some might. -DES ^Talk 02:07, 20 June 2009 (UTC)

It could be useful for comparing to other bibliographies published that way, and spotting the mis-matches in both directions fairly easily. Kevin 02:20, 20 June 2009 (UTC)

Well, the original design assumed that the Summary Bibliography page would be as important as the Alphabetical page and the Chronological page. However, since the Summary page is our default, it proved to be much more popular than the other two pages, so it is now thought of as our "standard biblio page". In addition, few of the changes that have been made to the Summary page over the last 3 years have been applied to the other pages (because Al was waiting for the design to stabilize), so the other two pages are now little more than "poor relatives".

It looks like we may want to do a few things. First, we need to whip the Summary page into shape, which will include the implementation of Chapbooks-as-containers and other things that we have on the Feature list and which can happen over the next few months. Second, we need to update the other important pages, including the Series, Alphabetical and Chronological biblio pages, so that they would reflect the current design/layout philosophy. Third, we need to consider whether we want to make the Chronological/Alphabetical pages more prominent by moving their links from the navbar to the top of the page. Fourth, we need to review the functionality that will exist after all these things are done and decide whether we need to create additional views of Author biblios. Ahasuerus 02:27, 20 June 2009 (UTC)

Fair enough. I just wanted to get this thought on record for consideration before I lost it. I didn't think it would be in the next round of software changes, even if everyone thought it was a great idea. -DES ^Talk 02:47, 20 June 2009 (UTC)

"Chapbooks-as-containers" is submitted for testing now, but "store user preferences" looks like a good idea too. For instance, we've already discussed whether switching off Images is desirable (and I think it is, if we want people to use the ISFDB software offline.) Series display is under consideration too, the "as by" seems to mislead at times, to the extent that people are creating variants just so something that was actually published shows up the way they want: showing all "actual" publications could be better. So many options, so much coding to do, so little time... I really do understand how Al feels at times. BLongley 23:51, 20 June 2009 (UTC)

Patch r2009-04

Patch r2009-04 has been tested and code reviewed. It will be going live later today (Saturday), probably around noon Eastern US time. Here is what will change:

• Bug 2799064 Fixed Advanced Search on Pseudonyms
• Bug 1743292 Fixed creating Variant Titles for Reviews and Interviews, which currently results in Author-less Titles
• Feature 2799068 Linked unmerged Titles to the affected Publication in the moderator screen
• Feature 1969497 Added Publication information to the moderator screen for Proposed Publication Updates (partial fix)
• Bug 2795822 Fixed the bug that resulted in duplicate Tags being generated when there were a lot of similarly titled Publications like Doctor Who and ...
• Feature 2799074 Displayed "held" Status and added a link to user Talk pages
• Bug 2797518 Fixed wrong links to the next page and author's records in Advanced Author Search results
• Feature 2803759 Changed the default Title Type in the Contents section from ANTHOLOGY to SHORTFICTION

In addition, the following changes will affect development/test systems only and have no impact on the live server:

• Bug 2806293 Fixed the problem that resulted in local database user creation failure.
• Bug 2806290 Updated the graphics on the Sourceforge site to match what's on the live ISFDB server.

As always, please report any issues or new bugs here. Thanks! Ahasuerus 14:17, 20 June 2009 (UTC)

Patch installed, test away! :) Ahasuerus 16:26, 20 June 2009 (UTC)

• The implemetnation of Feature 2799074 seems to be working just fine, and i love the link to the editor's wiki talk page. May well help people find the wiki. -DES ^Talk 16:33, 20 June 2009 (UTC)
• The impelmentation of Feature 1969497 also looks good to me. -DES ^Talk 16:47, 20 June 2009 (UTC)

Now it's live, I notice I forgot to correct "Pseudonymns". Ah well. BLongley 17:22, 20 June 2009 (UTC)

Yup, I noticed it during testing, but decided that it was more important to get the patch out quickly than to fix a typo, which we can always handle later :) Ahasuerus 17:58, 20 June 2009 (UTC)

I've used these and like:

• Feature 2799068 Linked unmerged Titles to the affected Publication in the moderator screen
• Feature 1969497 Added Publication information to the moderator screen for Proposed Publication Updates (partial fix)

BLongley 23:41, 28 June 2009 (UTC)

I've not used these, although I felt the need for them at one point: I think some people do like them though?

• Feature 2799074 Displayed "held" Status and added a link to user Talk pages
• Feature 2803759 Changed the default Title Type in the Contents section from ANTHOLOGY to SHORTFICTION

BLongley 23:41, 28 June 2009 (UTC)

I've not used these, and not seen anyone else use them either, although I felt the need for them at one point:

• Bug 2799064 Fixed Advanced Search on Pseudonyms
• Bug 1743292 Fixed creating Variant Titles for Reviews and Interviews, which currently results in Author-less Titles
• Bug 2795822 Fixed the bug that resulted in duplicate Tags being generated when there were a lot of similarly titled Publications like Doctor Who and ...

BLongley 23:41, 28 June 2009 (UTC)

I tried this, and something broke on the new PC. :-( Will investigate more.

• Bug 2806293 Fixed the problem that resulted in local database user creation failure.

BLongley 23:41, 28 June 2009 (UTC)

Series Bibliography display opinions wanted

While working on adding title type tagging to the Series Bibliography display, I noticed that in a case where some entries in a series are numbered and some are not, the titles are not displayed in chronological order. See, for example, the display for Black Widowers and also the display of the same series in Asimov's Summary Bibliography.

Do you prefer the current behavior be maintained, like so:

Bibliographic Comments: Series:Black Widowers Black Widowers Nothing Like Murder (1974) [SF] by Isaac Asimov Friday the Thirteenth (1975) [SF] by Isaac Asimov Earthset and Evening Star (1975) [SF] by Isaac Asimov The Cross of Lorraine (1976) [SF] by Isaac Asimov The Family Man (1976) [SF] by Isaac Asimov Variant Title: A Case of Income-tax Fraud (1976) by Isaac Asimov The Missing Item (1977) [SF] by Isaac Asimov The Sports Page (1977) [SF] by Isaac Asimov The Next Day (1978) [SF] by Isaac Asimov Irrelevance! (1979) [SF] by Isaac Asimov Variant Title: A Matter of Irrelevance (1979) by Isaac Asimov None So Blind (1979) [SF] by Isaac Asimov To the Barest (1979) [SF] by Isaac Asimov The Backward Look (1979) [SF] by Isaac Asimov Second Best (1980) [SF] by Isaac Asimov What Time Is It? (1980) [SF] by Isaac Asimov Middle Name (1980) [SF] by Isaac Asimov Neither Brute Nor Human (1984) [SF] by Isaac Asimov The Fourth Homonym (1985) [SF] by Isaac Asimov The Quiet Place (1988) [SF] by Isaac Asimov The Overheard Conversation (1989) [SF] by Edward D. Hoch 1 Tales of the Black Widowers (1974) [C] by Isaac Asimov 2 More Tales of the Black Widowers (1976) [C] by Isaac Asimov 3 Casebook of the Black Widowers (1980) [C] by Isaac Asimov 4 Banquets of the Black Widowers (1984) [C] by Isaac Asimov 5 Puzzles of the Black Widowers (1990) [C] by Isaac Asimov 6 The Return of the Black Widowers (2003) [C] by Isaac Asimov

or that the titles be displayed in pure chronological order, like so:

Bibliographic Comments: Series:Black Widowers Black Widowers 1 Tales of the Black Widowers (1974) [C] by Isaac Asimov Nothing Like Murder (1974) [SF] by Isaac Asimov Friday the Thirteenth (1975) [SF] by Isaac Asimov Earthset and Evening Star (1975) [SF] by Isaac Asimov The Cross of Lorraine (1976) [SF] by Isaac Asimov The Family Man (1976) [SF] by Isaac Asimov Variant Title: A Case of Income-tax Fraud (1976) by Isaac Asimov 2 More Tales of the Black Widowers (1976) [C] by Isaac Asimov The Missing Item (1977) [SF] by Isaac Asimov The Sports Page (1977) [SF] by Isaac Asimov The Next Day (1978) [SF] by Isaac Asimov Irrelevance! (1979) [SF] by Isaac Asimov Variant Title: A Matter of Irrelevance (1979) by Isaac Asimov None So Blind (1979) [SF] by Isaac Asimov To the Barest (1979) [SF] by Isaac Asimov The Backward Look (1979) [SF] by Isaac Asimov 3 Casebook of the Black Widowers (1980) [C] by Isaac Asimov Second Best (1980) [SF] by Isaac Asimov What Time Is It? (1980) [SF] by Isaac Asimov Middle Name (1980) [SF] by Isaac Asimov 4 Banquets of the Black Widowers (1984) [C] by Isaac Asimov Neither Brute Nor Human (1984) [SF] by Isaac Asimov The Fourth Homonym (1985) [SF] by Isaac Asimov The Quiet Place (1988) [SF] by Isaac Asimov The Overheard Conversation (1989) [SF] by Edward D. Hoch 5 Puzzles of the Black Widowers (1990) [C] by Isaac Asimov 6 The Return of the Black Widowers (2003) [C] by Isaac Asimov

If you prefer the pure chronological order, would you want to see that same ordering in the author's Summary Bibliography? --MartyD 10:09, 21 June 2009 (UTC)

I prefer the current behavior. Often there are items with a specific order (The Collections), but the stories themselves are merely part of the series with no inherent order. Kevin 12:49, 21 June 2009 (UTC)

I prefer the current. BLongley 13:09, 21 June 2009 (UTC)

I agree with the "currentists", but we may also want to consider whether we want to display all numbered items first as opposed to last. That decision was made in 2006 by a vote of 2:1 with neither side expressing a strong preference and we have accumulated quite a bit of additional experience in the last 3 years. Ahasuerus 14:23, 21 June 2009 (UTC)

That's a toughy. Items above are never confused as 'sub items'. but Items above (when excessive) can obscure the more detailed and sought after information. but Some series have been 'crafted' to take advantage of the 'above' behavior (i.e. a short unnumbered precursor story is intentionally not put in a subseries so it displays above the numbered items). Hmmm - Can 'I' cast a 2:1 vote? (chuckle). Kevin 14:48, 21 June 2009 (UTC)

I strongly prefer the current behavior to the "pure chronological" display. I weakly prefer having unnumbered items at the bottom. What I would strongly like is the ability to number sub-series so that multiple sub-series were in the proper order relative to one another. I would also very much like it if a work could be in more than one series, but I suspect this would require so major a redesign as to be impracticable. There is also the issue of insertions into series -- currently such changes require rather tedious manual renumbering of all later works. It would be nice if this could be handled automatically, perhaps with a move-up and move-down interface. But I'm getting off-topic. -DES ^Talk 15:01, 21 June 2009 (UTC)

The ability to assign numbers to sub-series was requested in Feature 2800713. It is certainly desirable and shouldn't be that difficult to implement (I know, famous last words). Allowing a Title to be in more than one Series has been often requested to support branching series, but wouldn't be easy to implement. Finally, we have found some Series with publisher-assigned non-numeric series identifiers, e.g. "17a" (sic!), but the Series Number field is limited to integers at this time. Unfortunately, it would require a fair amount of massaging and there aren't enough cases out there to justify making it a priority. Ahasuerus 15:29, 21 June 2009 (UTC)

Thanks. That's enough public sentiment for me to leave the status quo undisturbed. --MartyD 16:10, 21 June 2009 (UTC)

Mundania Press -- proposed merge

My atention was drawn to this by the recent Fixer submissions. We currently have threee publisher entries: "Mundania Press", "Mundania Press LLC", and "Mundania Press, LLC". I don't think these different forms add anything. I would like to rename them all to "Mundania Press" and merge them, but I don't want to do that without consulting others.

So -- would anyone object to such a course? If so, why? -DES ^Talk 15:18, 21 June 2009 (UTC)

Sounds reasonable to me. Ahasuerus 15:31, 21 June 2009 (UTC)

Fine by me. BLongley 15:39, 21 June 2009 (UTC)

Go for it. Kevin 15:49, 21 June 2009 (UTC)

Done. -DES ^Talk 17:11, 21 June 2009 (UTC)

Bug report: Trying to view merged publisher

Deriving from the above merge, if you now follow the first link to Publisher record #27461 (one of those dropped in the merge) you now get the following error

It would be nice if we displayed a more helpful error message, something like "Record not found: Publisher record #27461 is not on file" instead of a python error dump.

And by the way, what is the best place for such bug reports now? Should they be put somewhere on Development? Or should we create Bug Reports or perhaps Development/Bug Reports? Or go right to source forge? I am inclined to favor an initial post on the wiki before going to source forge, so reactions of developers and others can influence whether an how to make a source forge bug entry. -DES ^Talk 17:29, 21 June 2009 (UTC)

This one is fairly minor -- unless another Web site has a link to one of our Publisher records -- so I think we can just enter it in Sourceforge and it will get fixed eventually. Major issues, especially if we suspect that they were introduced in a recent patch, should probably be posted here to ensure quick turnaround. Ahasuerus 23:43, 21 June 2009 (UTC)

Data problem

I just got a nasty Python Error on a publication search by title (see here for the big message) caused by publication 68957 having no pub_ctype (i.e. it didn't know it was a NOVEL]. Editing the publication put it back:

but I'm not sure how the data was corrupted in the first place. Any ideas? BLongley 18:06, 21 June 2009 (UTC)

Here's some more examples if people want a look. They have very similar dates and record numbers. BLongley 18:06, 21 June 2009 (UTC)

Pub_ID Pub_Year   Pub_Title
68940	04/05/2005 47
68943	03/05/2005 Unspoken
68944	01/05/2005 Rainbow Magic #1: Ruby The Red Fairy : Ruby The Red Fairy (Rainbow Magic)
68958	03/05/2005 Guardian: Saviors of Kamigawa : Kamigawa Cycle, Book III (Magic: The Gathering: Kamigawa Cycle)
68959	01/05/2005 Monkey Business : Stories from Around the World
68967	05/05/2005 Star Wars Tales of the Jedi (Star Wars: Tales of the Jedi (Audio))
68972	05/05/2005 Star Wars Tales of the Jedi : Dark Lords of the Sith (Star Wars: Tales of the Jedi (Audio))

Well, May 2005 pre-dates ISFDB-2 by a number of months, so my guess would be that once we fix these 8 records, it's not something that we will have to worry about again. Hopefully :) The pubs look like Amazon imports, so it may been a problem with an early version of Dissembler. Ahasuerus 23:38, 21 June 2009 (UTC)

Feeling a bit rushed on this, so please comment fast

At the moment we have different series displays, depending on how you view them: e.g.

or .

I don't think either is necessarily right. I think we want to hide the "has never actually been published as" with an "as by" on the same line, whereas "published under both names" deserves a separate line for the variant. Go compare, contrast, discuss. BLongley 22:08, 22 June 2009 (UTC)

But there's a call for "standardise now, sort out the display later" that I'd like to challenge. I'd prefer we all look at these current display discrepancies, it shouldn't be restricted to those testing proposed changes, and I'd prefer that proposed changes don't have to be displayed like this - it's just one example and I've found contrary displays from the same author. But how many of you would review such? BLongley 22:08, 22 June 2009 (UTC)

Big data corruption issues need addressing fast, display issues like this do not, IMO. So I'd like a pause while we go find whether the problem is on record, as a bug or feature request, or even just something from an old conversation. "Making the problem go away for now" is not something I like. BLongley 22:08, 22 June 2009 (UTC)

I don't see a need to rush this unless it is in the way of other things. Frankly the differences between these two do not see to me to be a big deal. I fon't feel that either makes highly clear which works were and which were not published with a "non-M" author credit. In particular, was item #2, Rhapsody in Black, ever published as by "Brian Stableford"? Assuming that Brian without the M is the canonical name, I can't tell from either display. In fact the only work I am sure from either display was published as by "Brian Stableford" was the omnibus, because it has no variants at all. All the others have a variant, so i have no way to know if publication under the canonical name ever occurred, unless I drop to the pub level -- and if there are many pubs, I might easily miss one. :If one-line vs multi-line display is supposed to have significance it needs to be well documented, and even then I would expect most users to miss the significance of the distinction. As a purely esthetic choice, i could support "Use the one line form unless there is more than one variant" but this drops any attempt to give info about whether the canonical name/canonical title combo was ever published. Or I could support "never use the one line form" for consistency. But I don't think the difference between the one-line and multi-line form is sufficient to be a way to express actual data. -DES ^Talk 22:37, 22 June 2009 (UTC)

The single line "as by" behavior is an old display issue, which came up a couple of years ago and was put on the back burner when we couldn't find a good solution. Here is my current understanding of what's going on (copied from my Talk page):

Let's take a look at the Summary page for "Robert A. Heinlein". See how "Revolt in 2100" appears with [as by Robert Heinlein] at the end of the line? That's because we have 4 UK editions of this book which appeared as by "Robert Heinlein". Even though we also have a dozen editions of this book published "as by Robert A. Heinlein", as long as the VT and the main Title are spelled the same way, the software will display just one line for the Title. This is misleading and not what the original intent of this shortcut was -- the idea was that we would use the single line shortcut if (and only if) the Title has only been published as its VT. However, there doesn't appear to be a way to determine whether it's true or not without going to the Publication level for each Title, which can be quite time consuming when generating Summary pages for prolific authors like Silverberg and Asimov. I suppose we could add a Title level flag (which would be updated every time a related Pub was added/edited/deleted) to indicate whether this Title has only appeared as a VT, but that's a rather ugly and complicated workaround.

So the current behavior is certainly suboptimal, but we haven't been able to find a way to improve it, which is why it's still there. The multi-line solution is more accurate in many cases (including, in all likelihood, all of our Heinlein cases), but it can make the Summary page look unnecessarily "busy" when permanent pseudonyms are involved. We can certainly postpone making the display changes until we decide which behavior is preferred, I'll just need to re-juggle the contents of r2009-05, which is not a big deal. However, we do want to standardize the behavior of the Summary screen and the Series screens (which has already been coded) sooner rather than later since there is a number of other requested Series-related features in the pipeline and we don't want the code to diverge so much that it will require a rewrite. Ahasuerus 22:57, 22 June 2009 (UTC)

I can surely see your point. I understand what you say the original intent of the multi-line vs one line logic was, and the information it attempted to provide is information that a user might well want to have, but I maintain that, even if you could get the code to do consistently and without performance problems what you had originally intended it to do, this is a poor way to display that information (whether or not that title has ever been actually published in the non-VT form) because it is too subtle and most users won't correctly interpret it (IMO), even if it technically accurate.

Therefore I have a proposal. Abandon the idea that the one-line form will indicate something about how the work was or was not published, it will simply be used as a space-saver whenever possible. The logic would then be: whenever there is a) exactly one variant, that b) has its title spelled the same way as the parent record, then use the one-line form. In all other cases, use the multi-line form. Delay for later some way to indicate that the non-VT form (canonical title with canonical author name) never existed. -DES ^Talk 23:29, 22 June 2009 (UTC)

Actually I have a suggestion for that, too. In comparative linguistics, a word not recorded but inferred to have existed is shown preceded with an asterisk, this is "the mark of the reconstructed form" as I think Shippey puts it. So when there are no non-VT publications, put an asterisk before the non-VT title. This should be a 2nd phase. For one thing, it would have performance penalties unless we maintain a title-level flag for this, as Ahasuerus suggests above, and as he says that is less than elegant coding. So we may not choose to do this at all. If we do it, we probably need a legend to explain what the * means. But then we really already need a legend to explain what the various two-letter codes mean, and will need one more if we do go to different codes for the different story-length values, as has been suggested.

Anyway that is my proposal: standardize on "one-line wherever possible, multi-line when needed" and delay any indication of inferred but not recorded title/author combos for later. What so you think? -DES ^Talk 23:29, 22 June 2009 (UTC)

And if we do do a title-level flag it had probably batter be implemented as a counter, counting the number of non-VT pubs, and the test would be for a non-zero count. This would not require a full rescan of all pubs on every add/delete/edit; just an increment or decrement to the counter for the pubs affected by the edit. But that is for the future, IMO, and is a technical detail. -DES ^Talk 00:43, 23 June 2009 (UTC)

I think that there are two entirely separate issues here. One issue is that the Series Bibliography's display of titles is not consistent with the display of titles in the Summary Bibliography. Part of this is because the titles portion of the display is/was separate code, and part of this is because the newly-added display of variants likewise is/was separate code and doing things differently from the Summary Bibliography. A second issue is how should variant titles and their authorship be displayed. In my opinion, the first is a problem that should be solved -- and should be solved with centralized display processing -- before tackling the second issue. And since the series display in the Summary Bibliography (the top example) has precedence, the Series Bibliography should be made consistent with it. If we then want to change how variants and their authorship is displayed, we only have to make one change and in one place. I think it is a mistake to have multiple sets of code and multiple styles of display scattered throughout the program. It makes maintenance and enhancement difficult and error-prone. --MartyD 00:49, 23 June 2009 (UTC)

I think most IT people will agree with Marty's point about avoiding code duplication. On the other hand, I think Bill is raising the behavior issue now (rather than waiting for code reconciliation) because he is afraid that if we make the code consistent, the functional issue may fall off the radar screen and we may not revisit it for another year or two, which is also a valid concern. Ideally, we would decide on the desired display behavior over the next couple of days and implement it in r2009-05 to address both sets of concerns, but even if we do not, we could at least decide on the desired behavior and create a feature request so that the decision wouldn't be lost. Ahasuerus 01:16, 23 June 2009 (UTC)

I agree with the idea that the code should be centralized if at all possible. But I also think that we might as well develop a set of specs for that central code before we build it, otherwise the work will likely need to be done twice. Some elaborations may be deferred to a later phase, but I think we ought to know where we are headed before we start off. If this were a long-running unresolved debate it might be worth saying "just pick a way and standardize the code, then we can change it when/if they decide what they want" but we've only just started the discussion, and I don't see irreconcilable hardened positions here. Lets come up with at least broad specs for what we want the display to do, and then it can be written to do that. I don't think that need delay things so very much. 02:23, 23 June 2009 (UTC) —The preceding unsigned comment was added by DESiegel60 (talk • contribs) .

Well, technically, the question came up a couple of years ago, but I suspect that the only two people who were familiar with it at the time and who are still around are Al and me. I have been bugged by it for many months, but I couldn't think of a clean way to solve the problem, so I never raised it again. There are probably a number of issues like this one that I need to dredge out of my memory and put on paper in case anything happens to me and we lose this background information. Ahasuerus 03:28, 23 June 2009 (UTC)

"Paper"? How quaint. Unless you're planning to write a proper book on the history of ISFDB (and I for one would be tempted to buy such), publishing on the internet might help us more. I still haven't figured out where your collection is stashed, so paper records are likely to be of no help to me. ;-) BLongley 19:59, 24 June 2009 (UTC)

Performance & implementation

Would it be too much of a performance hit to just have the display page do the counting? When # under only VT Title = # under Parent title then use single line, else use multiple lines. Kevin 00:54, 23 June 2009 (UTC)

Unfortunately, the number of VTs is not dispositive in this situation since there are many cases when a book/story has never appeared under the canonical name, e.g. Dave Wolverton's The Runelords series appeared as by "David Farland". In a case like that, the current behavior of the Summary page (see links) is better than the behavior of the Series page, but in Heinlein's case the exact opposite is true. DES is quite right about the "reconstructed form" issue, but, as he noted, it would probably require a Title level flag :( Ahasuerus 01:16, 23 June 2009 (UTC)

If you mean count pubs, then I think it might be. There could easily be dozens if not hundreds of publications of a given title, and dozens or hundreds of titles for a given author. That could be thousands of db look-ups to correctly render a given page, increasing rendering time by 1-2 orders of magnitude. This is just theory, actual testing would be needed to confirm the actual time effects. -DES ^Talk 01:04, 23 June 2009 (UTC)

Note also that there can be multiple distinct variants, which must be displayed on multiple lines whether the parent form has any pubs or not, so the number of lines cannot be a reliable indicator for this datum. Look for example at 839804 -- three different variants of the author credit, all with the title identical. -DES ^Talk 01:04, 23 June 2009 (UTC)

I think Kevin meant "count VTs" rather than "count Pubs". The latter would most likely cause major performance issues and the former wouldn't help due to the problems that I outlined above. Damned if you do, damned if you don't... Ahasuerus 01:16, 23 June 2009 (UTC)

To clarify, when you view a parent title, the system has to display N publications, and when you display a variant title, the system has to display P publications. It could be reduced to two db lookups (per title with a single variant). If (whatever function checks for variants) then N = Select Count title_title where title_title = TITLE; and then P = Count title_title where title_parent = title_number but with an escape to skip this count check entirely if there are more than one variants. Maybe I'm over simplifying here, and I didn't check variable names, etc. Just a thought. Kevin 02:14, 23 June 2009 (UTC)

I think you are oversimplifying. The issue is not displaying pubs, done on a title biblio page, it is displaying titles, done on an author or series biblio page. In that case, to make the distinction desired, the query that really needs to be asks is: "Is the number of pubs that are not under a VT non-zero?" But that may require inspecting all pubs of all titles on the page, and that is likely to be a performance hit, unless the answer can be precomputed and cached as a title-level field, I think. -DES ^Talk 02:23, 23 June 2009 (UTC)

If I understand Kevin's latest approach correctly, he proposes to do the following for each non-VT Title after it has been displayed by the display logic:

1. Check if the Title has any VTs. If not, move to the next non-VT Title.
2. Check how many VTs the Title has. If more than on, display all VTs on separate lines. Done.
3. Check whether the single VT is spelled the same as the canonical Title. If not, display the VT on a separate line. Done.
4. Check how many Pubs there are for the canonical Title. If one or more, display the VT on a separate line. Done.
5. Otherwise display the VT using the "[as by ...]" convention on the same line.

Depending on how much extra processing time Step 4 will take and the number of affected Titles for the likes of Asimov and Silverberg, it may give us what we want at a reasonable cost. I'll run some tests tomorrow night unless someone else beats me to it :) Ahasuerus 03:37, 23 June 2009 (UTC)

My main argument is that this is not a good way to display the info determined in step 4. However, if we can determine that info at a reasonable cost, we can change "If one or more, display the VT on a separate line" to "if none, display marked with an asterisk" or whatever other display method we choose. Step 4 is the key. Note that if we use a display method for the result of step 4 other than one-line vs multi-line, steps 2 & 3 do not end the process, but proceed to step 4. After all, one title might have three variants but never have been published under the canonical title/author combo. Another might also have three variants, but have several pubs not under any VT. It would be nice to be able to detect the difference for that case also, which single line will not do, as both must be multi-line displays, since both have multiple variants. -DES ^Talk 04:04, 23 June 2009 (UTC)

Lets see how intensive doing 4 for the smaller subset is, then perhaps the check in 4 can be applied to the results of 2 and 3. Kevin 04:51, 23 June 2009 (UTC)

Got in one (err.. 5, and actually you improved on my idea). The processor 'cost' of 1, 2, and 3 are already in the system somewhere. Kevin 04:46, 23 June 2009 (UTC)

If I understand this suggestion correctly (essentially, current Summary Bibliography behavior but DON'T do the one-line [as by ...] if the canonical title has been published), I don't think an existence test would be too expensive in the specific case where there's exactly one variant and that one variant's title exactly matches the parent's. It does not need to be a count. Stay tuned for some screen shots. --MartyD 10:53, 23 June 2009 (UTC)

Do please consider the alternative: Similar to the current Summary Bibliography display, but mark with a special character listings where the canonical title/author combo has not been published (this is the abnormal case, we normally assume that any listing shown has been published). The coding other than the display part should be much the same, as should the performance implications. -DES ^Talk 12:54, 23 June 2009 (UTC)

If you make me a wiki text example of what you have in mind, I can mock that up and include with the examples below (might not get to it until tomorrow morning, though). My one concern would be how to do it in a way that would be meaningful to the people seeing it. But that's not to say any of the existing or proposed methods are meaningful, either, so I'm not sure that concern matters. --MartyD 13:56, 23 June 2009 (UTC)

Done. See User:DESiegel60/Mockup. -DES ^Talk 15:48, 23 June 2009 (UTC)

The promised screen shots. --MartyD 13:03, 23 June 2009 (UTC)

This is how the Grainger series would look (contrast with the two shots at the top of this discussion):

Compare with these two renditions of Daedalus Mission. This is how the Series Bibliography looks now:

This is how it would look (the Summary Bibliography looks -- and would still look -- like this, but with no "by Brian Stableford"):

And last, the Robert A. Heinlein Future History example Ahasuerus mentioned. Current display in Summary Bibliography:

Current display in Series Bibliography:

This is how it would look in the the Summary Bibliography:

And this is how it would look in the Series Bibliography:

Now that I see all of these together, my one stylistic opinion is that the "[as by ...]" is a helpful visual cue that the title is under a different name. I also did not notice any negative performance impact. Is this what people are thinking? --MartyD 13:03, 23 June 2009 (UTC)

Well I don't like losing the "Magazine/anthology appearances" from the summery display (those should not IMO be on the series display). I don't like the extra line for cases where there is only a single variant (as in the Grainger series), and i still don't like having some titles with a single variant display that on a separate line, and others not. I think it is more confusing than informative, and waists screen real-estate for information that could be both more obviously and more compactly indicated. But those are just my views. -DES ^Talk 13:17, 23 June 2009 (UTC)

Sorry, I misspoke/mistyped. Nothing would be lost from the Summary Display. I adjusted the above examples and added a shot of the Summary. Amount of text on the screen, however, would increase in some cases beyond what has currently been added for r2009-05 (the Grainger example). In the current r2009-05, if there is a single variant and its title is identical, there will ALWAYS be just one line, in both the Summary and the Series. Prior to r2009-05, that behavior was limited to the Summary, and the Series always displayed two lines. The examples above are a hybrid. --MartyD 13:48, 23 June 2009 (UTC)

Thank you, that is clear. My preference would be for something more like the r2009-05: Never use more than one line where there is a single VT with a title identical to the main one, but use a different mechanism to indicate the publication status of the main title/author combo. But if others like MartyD's proposal, so be it. -DES ^Talk 13:53, 23 June 2009 (UTC)

After reviewing the mockups at User:DESiegel60/Mockup, I think that the distinction between "also as by" and simply "as by" is a very useful one. That way we can reclaim a line of screen real estate while giving the user a good idea of what's going on with the title. (We may want to regularize the use of the upper/lower case, though.)

On the other hand, I am not so sure about the "asterisk convention". What it is trying to say here is that a canonical Title has only appeared as 2 or more Variant Titles, but the format doesn't look intuitive. I wonder if there may be a better way to convey the same thought? Ahasuerus 17:36, 23 June 2009 (UTC)

I have to admit that the proposed "asterisk" convention is not really intuitive. It is, at least, obvious as an indication that something is different about those titles. (And our current convention is IMO if anything less intuitive and easier to miss.) It would probably need to be accompanied with a "Legend" explaining (or linking to a wiki page explaining) our display conventions better. Indeed it could itself be such a link. But then, i think that some of the other codes now used ([SF], [O]) or proposed ([NV], [NT], [SS]) are note exactly intuitive either, and a legend would be useful for those also. Indeed a legend could explain that "variant title" often means a change of author credit and no variation in the title at all. Still if anyone can come up with a more intuitive indicator than the red asterisk, feel free. Perhaps [Implied] or [Canon.] or even [No pubs]? still any of these could be a bit confusing without a legend.

Oh as to case, I simply typed up the mockup, partly by cut&paste from current displays -- no attempt at a meaningful alteration of case was made. A coder should regularize that if following the mockup. -DES ^Talk 17:54, 23 June 2009 (UTC)

Glad you like "also as by". It came to me as I was constructing the mockup. -DES ^Talk 17:54, 23 June 2009 (UTC)

(after edit conflict) I have modified User:DESiegel60/Mockup to show the examples using "[no pubs]" insead of an asterisk. See what you think. -DES ^Talk 18:08, 23 June 2009 (UTC)

Hm, perhaps something like "also appeared as:" and "appeared as:" (or "appeared only as:") for the multi-line situation? Ahasuerus 18:05, 23 June 2009 (UTC)

Could work, but the asterisk is intended for "never appeared as". See what you think of "no pubs". -DES ^Talk 18:08, 23 June 2009 (UTC)

Well, "never appeared as" is the other side of "only (appeared) as:" in a multi-line situation, so I think the functionality would be the same, but the presentation angle would be more intuitive (hopefully). As far as "no pubs" goes, the single line version seems to be redundant since "[as by]" already implies after the introduction of "[also as by]". Ahasuerus 18:39, 23 June 2009 (UTC)

But "never appeared as" is the more unusual situation and the one IMO, that needs attention drawn to it -- when you see a listing in a bibliography the natural assumption is that the work "appeared". -DES ^Talk

I haven't checked the database, but "never appeared as by" [the canonical author name] happens in three common classes of cases. First, it happens when a book/story was published pseudonymously and never reprinted under the author's canonical name. This is very common among minor genre writers whose books appear on the stands for a few months, never to be seen/reprinted again. Second, it happens when the author has two (or more) common forms of his name, e.g. "Brian Stableford" vs. "Brian M. Stableford", and some of his books have only appeared using a non-canonical form. Third, some authors change their "working name" half way through the career -- e.g. Dave Wolverton/David Farland or Megan Lindholm/Robin Hobb -- and as long as we keep the original working name as the canonical name in the database, any book published using the second working name will be in the "never appeared as by" category. Ahasuerus 01:43, 24 June 2009 (UTC)

I agree with your three scenarios, and when I said that "'never appeared as' is the more unusual situation" I didn't mean it was highly rare in our db -- if it were I wouldn't bother so much about how to represent it. What I mean is that it is, as I understand it, unusual for a bibliographic publication to list, as if published, a form of title/author that did not, according to its own records, ever apppear. I know this is sue to our concept of canonical name, and the way the db works, and I am not suggesting that we try to change it. But it can be suprising for a user to find a listing for "The Halcyon Drift (1972) by Brian Stableford" or "The Old Nurse's Story" on the "Mrs. Gaskell" page, only to find that there is no pub of The Halcyon Drift with an author credit of "Brian Stableford" and no pub of "The Old Nurse's Story" with an author credit of "Mrs. Gaskell". So it seems to me that the often urged "priciple of least suprise" suggests that we should notify our users of this non-intuitive situation. -DES ^Talk 02:29, 24 June 2009 (UTC)

Oh, a variant of your second case is when an author has a well-established alternate name for a particualr genre, sub-genre, or series. Examples include J. D. Robb/Nora Roberts (both are actualy pseuds), Harry Turtledone/H. N. Turtletraub, Donald Westlake/Richard Stark. -DES ^Talk 02:29, 24 June 2009 (UTC)

And any given listing may not include an instance of "[also as by]", so i do not think it reasonable to expect the user to infer from the absence of "[also as by]" that the title/author in question never actually appeared. I think it is best to be as explicit as possible in this and similar matters, and not rely on inferences that only experienced and alert users of the ISFDB are likely to draw. -DES ^Talk 18:58, 23 June 2009 (UTC)

It is certainly true that any given Summary or Series bibliography may contain only one (or none) of the "as by" situations, but I think that the "[as by]" and "[also as by]" are reasonably self-explanatory. After all, this discussion's point of departure was a generally agreed upon observation that the currently used "[as by]" shortcut is misleading -- when and only the book has also appeared under the canonical name -- because it suggested that the book has only appeared pseudonymously. Now that we can display this type of books using the "[also as by]" convention, the "bad" connotation is gone. Moreover, "no pubs" may not be understood by our average user who may not even understand what we mean by "Publications vs. Titles", much less what the abbreviation "pub" means. Ahasuerus 02:22, 24 June 2009 (UTC)

You are correc that [no pubs] may be confusing to a user not an expert on our site. That is one of the advantages of the red asterixk. It clearly says that there is something odd about this listing, and if we provide a handy link to a legend page that explains more fully than any notation within a bibliography can do, we perhaps achieve maximum possible clarity. I do agree that jsut implemetning "also as by" helps a lot, but it doens't give any way to alert a user to those cases where a title has two or more variants, but never appeared under the canonical title & author. There are cases of this in at least two of the exampels in my mockup. Well I hope I have made my point -- are there other views to hear from? Perhaps an even better idea? -DES ^Talk 02:37, 24 June 2009 (UTC)

I had another idea for this last night. If people like "[as by ...]" and "[also as by ...]", how about using "[only as by ...]" for the on-liner case where the canonical title has never been published? Then "[no pubs]" could be limited to the unpublished parent in the multi-line case, where you wouldn't have the double-clutter issue. --MartyD 10:11, 24 June 2009 (UTC)

I'm leaning towards "[as by]" and "[also as by]" as good clean statements for the majority of the situations. In the case where there are multiple variants, and the 'constructed parent' under the canonical name never appeared (The multi-line 'Halcyon' Brian Stableford example), I would prefer the Asterik solution with Author Biblio pages appearing as "1 *The Halcyon Drift (1972)" and the series display page as "1 *The Halcyon Drift (1972) by *Brian Stableford". The asterik should not be separated by a space from the first letter (helping to identify it as connected with the info, not a pretty spacer or indent), and it should also appear immediately before the name in series display (indicating that the name is the key 'constructed' part of the record). Lastly I think it should be in black, not red. The idea is to indicate, not holler and shout. Kevin 02:54, 24 June 2009 (UTC)

My reasons for the Asterik are that any 'self explanatory' solution to the 'Never published as by' problem are going to create more questions than illumination on the part of the user. So if we cannot self explain, then we should choose not to explain on the display and and isntead choose to be as unobtrusive, (yet clear that something is up) as possible. Kevin 02:54, 24 June 2009 (UTC)

I believe we should develop an ISFDB - Key for 'users' of the database (Not editors, not moderators... just users) and add a link to the navbar on all pages (probably right under 'NavBar Help') called 'Understanding the ISFDB' or 'How to Read the ISFDB' or something similar and clear. Then put the obscure stuff on that page. Kevin 02:54, 24 June 2009 (UTC)

Of course, if others here don't think the info is worth making this explicit, so be it. The info can be determined from the actual list of publications -- although if the work is shortfiction included in collections/anthologies, you have to open the individual pubs to determine the matter. For display purposes, I think a certain amount of redundancy is often a good idea, and depending on the user to make inferences or note subtle distinctions, particularly across multiple displays or pages is often a bad idea, unless the users are all going to be heavy, trained users, which will not be the case for us.

Anyway, those are my suggestions and my reasons for them. I am surely open to alternate suggestions or to my ideas begin rejected altogether, but I hope that others will consider the basic ideas expressed in my reasoning here. I hope that my ideas have helped move forward to a solution better than the current one. -DES ^Talk 18:58, 23 June 2009 (UTC)

The discussion so far has been very useful and informative. After just a couple of days of brainstorming I think we are very close to a workable solution, which had eluded us for a few years. Many thanks to all the contributors!

Unfortunately, there is a downside to this level of Wiki activity. I have been trying to keep abreast of various topics and subtopics over the last few weeks and provide background information when needed, but it's a lot of work, especially in conjunction with all the testing/coordination/installation/backups/server maintenance/etc stuff going on. Most of it has been done at the expense of sleep and rest and at the rate we are going I will be completely exhausted in another week and have to take a vacation. With this in mind, in a few minutes I will try to summarize the bare minimum of the changes that we all more or less agree on and see if we can have them coded, tested and implemented for r2009-05. Once the behavior is consistent between the two affected pages and we see what we have at that point, it should be easier to agree on the next set of changes. Ahasuerus 02:39, 24 June 2009 (UTC)

Proposed Preliminary Approach for r2009-05

For every displayed canonical Title, the software will:

1. Check if the Title has any VTs. If not, move to the next non-VT Title.
2. Check whether the canonical Title has no pubs directly associated with it (not counting any pubs associated with its VTs). This information will be used in subsequent steps.
3. Check if the Title has more than one VT, in which case display the VTs on subsequent lines. If the canonical Title has no pubs (see Step 2), then also print "only appeared as:" on the canonical Title's line. Move on.
4. We are here if there is a single VT. Check if the VT is spelled the same as the canonical Title. If not, display the VT on a separate line. If the canonical Title has no pubs (see Step 2), then also print "only appeared as:" on the canonical Title's line. Move on.
5. We are here if there is a single VT and it is spelled the same way as the canonical VT. If there is more than one pub for the canonical Title (see Step 2), display "[also as by]" on the same line and move on.
6. Otherwise display the VT using the "[as by ...]" convention on the same line.

If there are no major issues with this approach, we can ask Marty to mock it up since a picture is worth a thousand words. Ahasuerus 03:01, 24 June 2009 (UTC)

I will do this. One possible issue: the proposal here ends up doing an extra database query for every title with variants (as opposed to doing so just for titles having exactly one variant and then only if the titles are identical). There may be performance implications. The look-up has to be done against one of the biggest tables. --MartyD 11:11, 24 June 2009 (UTC)

I think I can live with the above -- I hope it will be fairly clear that "only appeared as:" applies to the line below. I look forward to the mockup. I would point out that the wording "only appeared as:" implies a level of assurance many of our records don't possies -- that we have no record of a pub does not mean it never existed. I am mostly confident that the presence of a record means a pub matching it probably existed -- I am far less confident that the absence means it never existed. But the above will do, though i would still prefer the asterisk plus key (legend). -DES ^Talk 11:59, 24 June 2009 (UTC)

Here are the pictures. I did not like the way "only appeared as: " looks in the Daedalus Mission display, so I took the liberty of producing another variation modifying that case (the one-liner) to use "[only as by ...]" instead (not affecting the proposed changes to the Grainger or Future History displays). For DES' sake, I've also included what Mrs. Gaskell's Short Fiction section would look like (using the "[only as by...]" variation). --MartyD 14:54, 24 June 2009 (UTC)

Future History -- demonstrates "[also as by ...]":

Grainger -- demonstrates "only appeared as:" in multi-line scenario:

Daedalus Mission #1 -- demonstrates "only appeared as:" in single-line scenario:

Daedalus Mission #2 -- demonstrates "[only as by ...]":

Mrs. Gaskell -- how the additional example from User:DESiegel60/Mockup would look (using the "[only as by ...]" variation):

I hope that is helpful. BTW, I will have only limited availability the next two mornings and no availability the rest of the weekend to do anything with this, so if further mock-ups are needed, someone else may have to do them, or they may have to wait. If anyone wants to see a shot of a specific Summary or Series bibliography display using one of the above techniques (let's call them "r2009-05", "hybrid", "only appeared as", and "[only as by ...]"), let me know on my talk page, and I'll run the appropriate variation and post the shot(s) somewhere in the Development area. --MartyD 14:54, 24 June 2009 (UTC)

It is helpful. I also prefer the look of the second Daedalus Mission example. One point. In the "Mrs. Gaskell" example, was "The Old Nurse's Story" ever Published under the name "Mrs. Gaskell"? The answer is that we have no record of such a publication, but this can't be determined from the screenshots above. Ahasuerus's proposal seems to call for the text "only appeared as:" in this case, but it is not in the screenshot. Was that an oversight, or an intentional change? Still I think this is a significant improvement from what we started with just a few days ago. -DES ^Talk 15:24, 24 June 2009 (UTC)

It appears to have been published as such in THFNTNBKFG1971, THFNTNBKFG1964, and SMLLSHDWSC1974, which is why it appears with no trailing label. --MartyD 16:12, 24 June 2009 (UTC)

My error, and my apologies therefor. I should have double-checked before posting above. -DES ^Talk 16:17, 24 June 2009 (UTC)

Oh, an odd note of synchronicity, not really on point here, but I couldn't resist. I ran into Mrs. Gaskell when doing some entry work on Victorian Ghost Stories: An Oxford Anthology and the pubs listed in its "sources" section. That is why i used her as an example above. Then last evening I was re-reading Ursula Le Guin's collection The Birthday of the World and there was a reference to Gaskell in the introduction, as a prototype of the form used in Four ways to Forgiveness. Le Guin also referred to "fixup" as a "sneering, British term", and while the "sneer" might be debated, the "British" is simply wrong. Even Jove nods. -DES ^Talk 15:24, 24 June 2009 (UTC)

"Daedalus Mission #2" definitely looks better -- that's why a picture is worth a thousand words! :-) One minor point, which I meant to document in the "6 Steps" above, but apparently failed since it was quite late. We may want to enhance the multi-line display logic, e.g. "The Old Nurse's Story", to say something like "also as:" on the first line when the title has appeared both as its VTs and under the canonical title. Other than that I think it's ready to be committed to Sourceforge for testing. Ahasuerus 17:20, 24 June 2009 (UTC)

I will add it as "also appeared as:", which will be parallel to "only appeared as:". Are you going to log the Feature Request to redo how variants are displayed, or shall I? I also need a call on whether this should go on top of the nav bar changes. --MartyD 17:36, 24 June 2009 (UTC)

Sure, I'll create the Feature request. Upon consideration I am afraid we'll need to branch since pushing both sets of changes out at the same time would be iffy, especially given your limited availability over the next few days. Don't worry, Kevin, we'll get your navbar changes out there soon enough! :) Ahasuerus 17:51, 24 June 2009 (UTC)

Feature request 2811692, "Improve display of VTs", created; "also appeared as:" added. I also corrected Step 5 to read "If there is at least one pub for the canonical Title..." Ahasuerus 18:22, 24 June 2009 (UTC)

(unindent)Re: DES's request for a key/legend. Regardless of whether we implement asterisks, we probably need to have a separate static page with a list of all abbreviations that are used in the system, e.g. "pb", "tp", "ph", "[SF]" (which has been questioned due to the potential for confusion with "science fiction"), "[ES]", etc. The data could be kept either in a Python script or on a Wiki page, but we will need to have a consistent pointer to it from all ISFDB pages. If this sounds reasonable, I can create a Feature request and we can address it in the coming weeks. Ahasuerus 18:08, 24 June 2009 (UTC)

Since I asked for it, i created FR 2811725 Legend for biblio display pages. -DES ^Talk 19:28, 24 June 2009 (UTC)

Lessons learned from the recent discussions

A couple of things have come into focus during the last few days.

First, there has been a mix of technical and behavioral issues posted on the Community Portal over the last few weeks. When editors use SQL queries and other techno-speak here, it scares non-technical editors away and they stop participating in the discussion. This leaves the field to just a few technically savvy editors whose preferences and priorities may not be the same as the preferences of the larger community. We need to make sure that technical discussions are limited to the Development page (and/or its associated Talk page) and that all posts on the Community Portal can be understood by people who have never seen a MySQL table (and have no desire to be introduced to one.)

Second, the order in which updates are applied is a "process issue" as opposed to an application behavior issue. Behavior issues, i.e. how the application should behave, are decided by consensus, but, as stated above, the administrator du jour (which means me at the moment) will be making decisions on process issues. Failure to do so can result in collisions between different development paths and general stress as we have seen with r2009-05. I'll try to do a better job of keeping the stress level low and will also investigate ways to minimize the number of collisions between different developers.

Finally, we need to remember that the recent development paradigm shift from "Al knows everything and takes care of everything" to "distributed development by a group of people who know little about the inner workings of the application" is liable to result in all kinds of growing pains, so let's try to take it in stride and not stress out too much. Ahasuerus 20:44, 24 June 2009 (UTC)

I tend to agree. I almost moved some of the discussion to ISFDB:Proposed Interface Changes, where it would probably have been better placed from the start, but it was already being followed by enough people to make that seem awkward to me. I did try to split the more technical stuff into a sub-section, but that didn't wind up having the desired effect, probably because I didn't do it well. Still I thought this went better than many discussions in the past have. -DES ^Talk 21:12, 24 June 2009 (UTC)

Well, the good news is that, unlike various inconclusive discussions in the past, we were able to come up with ideas that let us address a long standing problem in just 3 days. The bad news is that doing things out of order resulted in "branching" (i.e. software divergence) and put a significant (and I mean significant) amount of additional stress on the development team. In the future, we need to organize discussions in a way that will let the design/brainstorming work occur without affecting ongoing development. Then we'll have the best of both worlds :-) Ahasuerus 22:48, 24 June 2009 (UTC)

How could that have been done this time? Did we need to have this discussion sooner? I don't quite see how we could have. Should other development have been deferred until this was discussed and perhaps implemented? Or is it that having had a discussion, implementation work was started at once without determining that this would imply a branch? I don't see that the issues of VT display were so urgent that development on them couldn't wait until other code was checked in and tested, and perhaps released, thus avoiding a branch. But perhaps they were a bottle neck to other things. -DES ^Talk 23:00, 24 June 2009 (UTC)

It's a rather long story, I'll describe the gory details tomorrow once my batteries have been somewhat recharged :) Ahasuerus 01:38, 25 June 2009 (UTC)

(Unindent) Batteries partially recharged, on with the story.

First, let's review how we got here in case some of us have lost track.

Originally, Al created all Author pages, i.e. the Summary Bibliography page, the Alphabetical Bibliography page and the Chronological Bibliography page, equal. However, since the Summary page is the default page for Authors, the development effort concentrated on the Summary page with the understanding that the other two pages would be brought up to the same standard once the Summary page was stable. Of course, it never became completely stable, so eventually the two other pages fell far behind, missing proper support for variant titles and all kinds of other things that we have added to the system over the last 3 years. We also expected to overhaul the Series page once we knew how we wanted it to behave, but that never happened either.

Fast forward to early June. Bill partially implemented Feature 2804561 ("Make the appearance of Series VTs and title types ([SF], [C], [O], etc) consistent with the way they appear on the Summary page") by adding variant titles to the page. The change didn't duplicate the VT behavior of the Summary page exactly since Bill wanted to demonstrate another way of doing VTs and start a discussion. I tested the change and incorporated it in r2009-03 since I figured that it was harmless enough and that we were going to have a complete solution soon.

Next, Marty submitted a change that would have made the Series page behave the same way as the Summary page, overwriting Bill's changes. Bill raised this issue on the Wiki and requested that we come up with a decision re: how we actually want the software to behave rather than accepting the status quo ante as the default standard. That started the latest round of discussions, which eventually resulted in additional modifications which have now been implemented and are undergoing testing. In the meantime, Kevin changes overlapped with Marty's, which necessitated branching. Much stress ensued.

In retrospect, most, if not all, of the stress could have been avoided if I hadn't accepted Bill's original partial change, which made different screens behave differently. Instead, I should have analyzed Bill's solution, compared it with what we already had and posted the results here so that we could decide on the preferred behavior. I'll make sure to do better next time. Ahasuerus 04:39, 26 June 2009 (UTC)

That's not quite what happened. I never intended to work on Feature Request 2804561 - in fact, you can see that that was only created 4 days after I'd submitted my changes. I was working on Feature Request 2800716 ("Add parent series to series display") when I noticed that variants weren't displaying at all, so added that as a second code change as it was a quick copy of the code from the title display (biblio/title.py). There was no particular bug report or feature request I could find at the time, but it was obviously wrong. (Nowadays I guess we'd demand the bug report before accepting that second change - but we could have accepted the first alone in the meantime.) BLongley 18:51, 26 June 2009 (UTC)

A while later I noticed that despite it being a direct code copy, it still wasn't consistent with the main bibliography page. Not a problem for me as it never had been consistent anyway, my change was an obvious improvement, and I hinted that people might want to compare at some point. I didn't have time to investigate further then. I did get concerned when the new feature request seemed to be implying "that screen is right, that one is wrong" without fuller discussion. I'm glad we're having that now, although the way we got there isn't ideal. My one last nagging doubt is about what we're still going to be inconsistent with - after all, when I copied the code I kept it consistent with the title display, and we don't seem to have been including that in the "make the displays consistent" discussions. (Although I'm not caught up on all the discussions yet and may be wrong on that.) BLongley 18:51, 26 June 2009 (UTC)

Anyway, many thanks to Ahasuerus for managing this - we've actually had more releases of ISFDB improvements this month than my delivery manager has arranged this year at my day-job! Definitely time to take a break and unwind a little, I think, it's been earned. BLongley 18:51, 26 June 2009 (UTC)

Thanks for the clarification and the kind words, Bill! I assume that your delivery manager has a more complex application to supervise, though :-)

r2009-05 has been installed and looks good so far. I'll update the Sourceforge "artifacts" tomorrow once it's final. Also, I will have a fair amount of free time next week, so I will try to do some Python coding on the side. I'll select a few simple features, post them here and, if there are no issues with their implementation, tag them as "approved" in Sourceforge. Ahasuerus 04:38, 28 June 2009 (UTC)

Approving Feature Requests

There is also another "process issue" that we need to discuss. The Development page currently states that new functionality is implemented in the following fashion:

1. A developer selects a bug to fix or a feature to implement.
2. The developer posts about his intent on this page to avoid effort duplication.
3. If there are any questions about the desired behavior of the software, they are posted and addressed on the Community Portal.

This is fine for bugs and minor enhancements that are unlikely to cause controversy, but we have 79 outstanding Feature requests at the moment and some of them are fairly major. It would be a shame if a developer spent a lot of time implementing a feature only to find out that many editors don't like the implementation or, worse luck, don't agree that the feature is needed/desirable. For example, I once requested that we "Default author on collection contents" (feature request 2800763), but is it really how we want the software to behave? Ahasuerus 04:39, 26 June 2009 (UTC)

I like that, but there's other considerations. Which I've added at Sourceforge, but not here. (Yet.) You might use that as an example of impact assessments (technical and user), cross-referencing related changes, what we should be posting there and what here, etc. BLongley 19:48, 26 June 2009 (UTC)

In order to avoid this kind of problems, I have created a new "Group" for Feature Requests. Anyone can create a new Feature Request, but it won't be eligible for implementation until it has been marked as "Approved". We will need to post a list of all outstanding features and decide which ones are "approved". I suspect that most won't be controversial, but some may need additional design work. Ahasuerus 04:39, 26 June 2009 (UTC)

That sounds like a reasonable approach. Where do you want the list posted? A new sub-page of Development, say Development/Outstanding features? Use the existing ISFDB Feature List once we finish transferring the old stuff to source forge? Create a new ISFDB Feature List/Outstanding features? Use ISFDB:Proposed Interface Changes? Or somewhere else? -DES ^Talk 14:34, 26 June 2009 (UTC)

That sounds like a very cumbersome approach. It essentially means that no code work should be started until approved, and often the possibilities are not obvious until a developer has taken a look at the code and started considering changes. Has any thought been given to a 'branching' development process, where each developer branches the code, works as before, and then selected changes are merged back with the mainline? Primarily it would only require additional documentation of which functions in each file you modify. Then you could select individual code functions for each change, instead of choosing files for each change. Another route to consider is patches. If, instead of committing code for testing, we instead uploaded patches to each feature or bug... then anyone could download and deploy the patch, play with it, experiment, and then only after Approval and Testing is code committed to the cvs mainline branch. Kevin 14:49, 26 June 2009 (UTC)

I think you can start code changes - after all, that's often the only easy way to create a demonstration of your proposed design. I think where we might need to hold back is on committing the changes. CVS is pretty good for allowing such a style of working, as opposed to some tools that force you to decide up-front whether you're branching or locking the code you're working on. BLongley 19:30, 26 June 2009 (UTC)

Given that the wider discussions only seem to take place when we're posting screenshots and talking about the proposals here (we have far more opinionated users than we have technically capable and interested testers), I think this is a good idea: but we might want to separate the technical issues and the interface design issues. For instance, I prefer to avoid working on any code that is being modified for some other reason, so analysing a feature far enough to say what modules you want to work on is good, but is of no interest to the general users. But when you're talking about what the end-user will see changed, you need that discussed by everyone. So I can see a possible need to split what is discussed in the general ISFDB User Wiki with what is discussed at Sourceforge (if that's where we decide the techies should talk) or on a specialist techie Wiki area here. What I don't want is to split discussions over multiple talk-pages, or start taking things to private email, or putting user interface discussions on techie pages alone, or inserting too much techie talk in the general discussions. I think we need two areas, and they will overlap and need cross-referencing, but I don't want too much fragmentation and I definitely don't want any discussions hidden. BLongley 19:30, 26 June 2009 (UTC)

That's pretty much the direction that I was taking although the details still need to be worked out. I'll start a simple Feature-specific section on this page as an experiment and see where it takes us. Ahasuerus 02:40, 29 June 2009 (UTC)

One thing that I can see a need for soon is to have someone/some people look at all the outstanding change requests (both bugs and features) and assessing which need to be considered together. A big task, yes, but we've already had developers work on totally opposing requests (user discussions needed) and I've found clashes on certain code modules for completely unrelated requests (techie discussions needed). Of course, we can post such information as we find it, but it's better to know that a request has been compared with all other requests rather than assume that because one clash has been identified that there aren't others, or that no clash report means there are no clashes. I think that full assessment is the point we want to set "Approved" status and any new features added after need to be compared against "Approved" changes. BLongley 19:30, 26 June 2009 (UTC)

I suspect that for simple Features we can get away with rudimentary "requests for comments" on the Community Portal. If we can quickly get, say 50% of the current features either "Approved" or "Denied", then the remaining features will be easier to handle. I may well be wrong, though, since I may be overlooking some complexities and dependencies. Ahasuerus 02:40, 29 June 2009 (UTC)

Non-genre series with omnibus -- a bug?

Consider the Fox series. Every title in this series is of type NONGENRE except for two titles of type OMNIBUS, both of which contain only titles of type NONGENRE. Looks like a non-genre series, right? But on the Kenneth Bulmer page, it is listed in Fiction series. I suspect it is the two Omnibus titles. It seems to me that a series with only NONGENRE and OMNIBUS titles should be listed in the Nongenre Series section. Or have I misunderstood what is going on here? -DES ^Talk 15:54, 26 June 2009 (UTC)

Yeah, as we don't distinguish Non-Genre Omnibus from Genre Omnibus (and could we always do such anyway?) I think the software gets confused. Something for MartyD to consider maybe, along with all the other headaches we've given him recently. ;-) BLongley 20:06, 26 June 2009 (UTC)

I think the design decision needed is either on how a human should classify an Omnibus better (new title-type?), or how the software should determine the status of an Omnibus as Genre or Non-Genre (or maybe even as Non-Fiction) based on its contents. E.g. if a boxed set of the Narnia novels comes with a book of commentary/literary criticism of such, do we make it fiction on a 7:1 ratio basis? If "2001: A Space Odyssey" gets bundled with "The Making of 2001, the Movie", where does it fit? Decide on page-count of the individual titles as to whether it's more non-fiction than fiction? (I don't think that could be done in software.) BLongley 20:06, 26 June 2009 (UTC)

I think we can do something simpler and less problematic. Currently, If a series consists of ALL non-genre works, it is classed as a Nongenre Series, but if it has any titles of type NOVEL it is a Fiction series. I think this is fine. But currently also, if three is an item of type OMNIBUS, the series is also of considered to be a a fiction series. That last is what I would change: if a series consists of one or more items of type NONGENRE, one or more items of type OMNIBUS, and zero items of type NOVEL or SHORTFICTION, then i would make it a nongenre series. Yes it is in theory possible that such a series would have SF content buried in the OMNIBUS, but if the series is set up properly, any omnibus contents would themselves be listed as part of the series, ans so if they are SF they would move the series into the fiction series section, without regard for trying to figure out anything about the omnibus. This has the advantage that it should give the correct answer in all non-pathological cases; it does not require a change in DB design; it does not require the software to try to classify an omnibus as either SF or nongenre, it simply says that an omnibus doesn't count for that decision. It should only require a minor change to the display code that decides in what section a series is to display. -DES ^Talk 20:37, 26 June 2009 (UTC)

In your (Bill's) example, if an omnibus consisted of "2001: A Space Odyssey" and "The Making of 2001, the Movie", and this was part of a series (remember that the issue only arises AFAIK for items in a series), then presumably "2001: A Space Odyssey" would be part of the same series. In which case that series would display as a fiction series, because it contains a NOVEL, no matter what else is in it. Does that make sense? -DES ^Talk 20:37, 26 June 2009 (UTC)

It makes sense, but is probably an oversimplification. 2001 the Novel is already part of a series of novels so couldn't be part of a series of "The Making of..." books too. Not that we have any yet, and the Making of Kubrick's 2001 actually only includes "The Sentinel" - I may be looking too far ahead. But this will probably be a concern until titles are allowed to be in multiple series. BLongley 13:13, 28 June 2009 (UTC)

If an omnibus contains works in two different series, the omnibus itself probably shouldn't be part of either. I'm not sure what would happen with a publications series, but I'm not super fond of those anyway. Can you find an actual case where an omnibus including fiction is part of a series that contains otherwise nothing but works of nonfiction? -DES ^Talk 13:23, 28 June 2009 (UTC)

No, but I can point you to a non-fiction sub-series that doesn't appear with it's sister fiction sub-series. Katherine Kurtz - See the nonfiction subseries Deryni Magic. Off topic I know, but something to look into fixing. If a nonfiction series were to have an omnibus that included fiction, I would suspect Jerry Pournelle, James P. Hogan, Isaac Asimov, or one of the other folks who have written extensive non-fiction series collections, and often base a piece of fiction on the non-fiction work (Getting paid twice for the same research - Haha!). But after racking my brain for 5 minutes or so, I'm not coming up with any. Kevin 15:19, 28 June 2009 (UTC)

Having a related but non-fiction series in the non-fiction section doesn't sound like a problem to me. Most of the stuff in Deryni Magic would probably be classed as "fictitious essay" when/if we create that type anyway, and at that point the issue would probably be solved -- that type should probably group with fiction. -DES ^Talk 15:50, 28 June 2009 (UTC)

My lapse of memory, its been a while since I read those. But if they are critical discussions, then IMO they should display separately. I surely wouldn't want a series of critical works about Tolkien (and there are several) appearing in the same series as The Lord of the Rings. -DES ^Talk 17:14, 28 June 2009 (UTC)

Actually IIRC it considers itself a serious examination. I know that the one book in the series I own, has extensive cross references by page number to incidents, examples, etc within the fiction universe. Off hand, I would call it a Critical discussion, especially the expanded edition with Reginold contributing. Kevin 16:28, 28 June 2009 (UTC)

In any case, can you see an example or think of a plausible detailed example, where my proposed solution of "an omnibus neither makes a series genre fiction nor non-genre, it just doesn't count" would lead to a bad result, to the point where we would really need logic to look at the contents of the omnibus to try to determine the "type" of the omnibus? Given that our current logic calls a series "genre" if it has even one genre work included. -DES ^Talk 15:50, 28 June 2009 (UTC)

Well, there are series entirely of Omnibuses, e.g. the Sidgwick & Jackson Science Fiction Specials - so if we make them not count, there's nothing left to count without looking at contents. BLongley 16:06, 28 June 2009 (UTC)

Ah that would be a publication series. Well, by default, put such in fiction (genre) series, or create an "Omnibus series" section for display, just as we now have "anthology series". I doubt we often, if ever, have publication series devoted entirely to non-genre omnibuses. -DES ^Talk 16:16, 28 June 2009 (UTC)

Agreed, the S&J SF Specials are a Publication (or even a Publisher) series. But such are not always as simple, hence this page. I'm a bit suspicious of Doc Savage as being truly Spec-Fic - if even some of those are ever demoted then that would be another good set of example headaches. (From my point of view, they seem as Spec-Fic as "James Bond" - and there's only been one of those I'd have considered allowing in, on the grounds that the Novelisation of Moonraker the film was a bit far-fetched for its time.) BLongley 21:13, 28 June 2009 (UTC)

I highly advise against an Omnibus Series section. There are several examples (2 easily found by search for series 'Omnibus', and I know I've seen others) where the omnibus' have been put into a separate sub-series. Such a decision would remove them from the fiction series area all together if/when alone in a series (As shown with the non-fiction example I brought up above). Kevin 16:28, 28 June 2009 (UTC)

The Omnibus Series that always give me a headache are The Tale of the Eternal Champion (Millennium) and The Tale of the Eternal Champion (White Wolf). (Just providing examples, I have no better suggestion for such yet.) But at least either would benefit from being assumed to be Fiction. BLongley 20:57, 28 June 2009 (UTC)

Fair enough, then leave them in fiction by default. There shouldn't be such a thing as a purely non-fiction (as opposed to non-genre) omnibus anyway, since we define an OMNIBUS type as including at least one novel. An omnibus edition of several non-fiction works should probably just be entered as NONFICTION. -DES ^Talk 16:39, 28 June 2009 (UTC)

Unfortunately NONFICTION omnibuses of NONFICTION contents do not work - you either have to omit the contents (in which case there's no link to the standalone titles), or you have to enter them as OMNIBUS. This is a general problem with most container title types - which is why COLLECTIONs of COLLECTIONs don't work either. BLongley 16:59, 28 June 2009 (UTC)

I do understand that. What I meant was that given that non-fiction is somewhat peripheral to our purpose anyway, and that omnibus editions of non-fiction works that we would index are somewhat rare, although not unheard of, I would index such volumes as simple NONFICTION, and list the contents only in a note. (I think that is how our help should be read currently.) Not perfect, but I think it is the best way to handle such until/unless we create a non-fiction omnibus type, and I'm not sure I would favor doing so. I rather doubt the need. (For the matter of that, putting a collection in an omnibus isn't perfect either, since you can't see the3 individual contents of the collection -- some of which may even be novels -- or else you can't see the collection as a whole. -DES ^Talk 17:10, 28 June 2009 (UTC)

Well, with Omnibuses of Collections and/or Anthologies (and/or Novels, Novellas, Essays, etc) you can (and should) enter both the overall longworks and the shortworks to get all the links working, and they display correctly. (You can't do Omnibuses of Omnibuses though, but I can't think of any offhand.) BLongley 17:52, 28 June 2009 (UTC)

Anyway, do you see this issue, or indeed any other issue, as a serious obstacle to my proposal to have omnibuses not affect the genre or non-genre status of a series, at elast if it contains any non-omnibus titles? -DES ^Talk 17:10, 28 June 2009 (UTC)

Not immediately, but I'd rather build this up into one solid feature request rather than fragment it. For instance, some of today's experiments with Chapterbooks indicate that those can have the same sort of problem. Even if we don't get many publications like this. BLongley 17:52, 28 June 2009 (UTC)

(unindent) One long term solution that has been occasionally suggested is creating a new Title level field for NONGENRE and moving this information out of the main Title Type field. That way we can easily distinguish between genre and non-genre Collections, Anthologies, Short fiction, Non-fiction, etc and not have to worry about overloading the Title Type field. Ahasuerus 23:29, 28 June 2009 (UTC)

IMO, Series need to have their own type, rather than having it be determined by the types of the titles within the series. In addition to Omnibus, Collection and Anthology have the same behavior/effect. An interesting behavior, independent of Omnibus, is that for two authors contributing different types of works to a series, the series will be displayed as one type in one author's bibliography and another type in the other author's. --MartyD 01:15, 29 June 2009 (UTC)

Well, we could create a new field, "Series type", in the Series table, but what happens if a new title is added to the series which changes its type? For example, if previously uncollected stories are published in a standalone collection, will we need to edit the Series record to change its Series type? Ahasuerus 02:08, 29 June 2009 (UTC)

I think assigning a type to a series would complicate both the interface and the programming, to little gain, and perhaps some actual loss. Currently, putting a work in a series is simple: you just add the series name to the proper field in the title record, and optionally the number in the series. Creating a new series is so simple you may not know you've done it -- just add a series name not previously recorded to to a title record. But if a series is to have a type, some editor must at some point select the type. Or if the type is picked up automatically from the works in it, how is that different from the current situation. And if an existing series has type GENRE FICTION, what happens when a NONGENRE work is added to it? It is not permissible to forbid the addition -- there are series that include both genre and non-genre works. I don't see a gain to match the cost of assigning a type to a series. -DES ^Talk 02:46, 29 June 2009 (UTC)

A gain is the series placement would be consistent and would NOT change just because someone added a non-fiction title or non-genre title to a fiction series. Another gain is that the issue being discussed above would be solved without the lights dimming as the code searches through the database for the types of all titles present in all container-style works in the series and any of its sub-series. The usability concern is easy to address -- automatic classification schemes do it all the time. Compute it automatically, make it editable, and record when it is manually overridden so that further automatic classification is not performed on it. --MartyD 11:07, 29 June 2009 (UTC)

The placement does not now, and would not under my proposal, change when someone adds a non-genre or non-fiction work to a series: series which contain at least one work of genre fiction are displayed as fiction series, no matter what else they contain, or how much of it. And my contention is that there is no need to look at the contents of contain types, although if there were such a need it would likely not cause huge performance problems, since the search would terminate as soon as one work of genre fiction was found. Compute automatically based on what rule, and when? But all in all, I don't see any significant gain, and if it allows a user to "override" such that series containing a work of genre fiction (including one added to the series after the "manual classification" is performed) are displayed in some other section, then IMO the result is simply wrong. Enabling wrong results is IMO not a positive thing. -DES ^Talk 12:43, 29 June 2009 (UTC)

Series type would give us better control over series placement. E.g. series type DEFAULT could result in current behavior, but changing it would enforce where the series is displayed. Now, if we have an essay series and a new text in the series is classified as SHORTFICTION, the complete series 'jumps' up in the bibliography to the Short Fiction Series section. (There is no perfect solution, as the Summary Bibliography is trying at the same time group together different types of works in the same series and split works into sections according to their types. Perhaps it would be better to have two views: one 'Works in Series/Works Outside Series' and another with series split according to title types: 'Novels in Series - Novels Out of Series - Collections in Series etc.'?)--Roglo 15:07, 29 June 2009 (UTC)

...As for the last remark, I see a wide range of choices in the earlier discussion (Proposed_changes_to_Series_display). --Roglo 15:28, 29 June 2009 (UTC)

It is at least arguable that if we have an essay series, adding a work of shortfiction to such a series would usually be a mistake. In just which actual, not hypothetical, cases would having a type property on a series provide a better outcome? I think this is a solution in search of a problem. -DES ^Talk 16:32, 29 June 2009 (UTC)

The 'essay series' often are columns and they do not necessarily have to be 100% uniform. But this is not critical. No, I cannot give you any example of 'mixed column' now. --Roglo 21:40, 29 June 2009 (UTC)

Much of the discussion in the thread linked above was devoted to the issues caused when non-genre and non-fiction series did not display at all -- this has now been fixed. There were suggestions of some sort of switch for how series should be displayed, which might eventually be useful for some, but I suspect relatively few would use in its non-default behavior, whatever the defaults were set to be. You did mention the concept of a series type, but it didn't seem to resonate with anyone else in that discussion. And there was discussion of the rule now followed by the summery bibio display code, that no title shall ever be displayed more than once -- a rule i am coming to believe is a mistake, but changing which would be non-trivial, i suspect. -DES ^Talk 16:32, 29 June 2009 (UTC)

I didn't participate in that discussion, just found it after making a remark on possible alternative layouts. --Roglo 21:40, 29 June 2009 (UTC)

This comment is a belated response to the original suggestion of ignoring Omnibus: It is a good idea. It is not, however, a simple change to implement because of the way the Summary Bibliography is set up to work. The behavior of the Summary Bibliography has been discussed at length elsewhere, so no point in rehashing that here, but the crux of the problem is that it displays titles only once and uses an order-based mechanism to determine the organization on the fly. If an Omnibus title were ignored and the series did not end up in Fiction Series, the Omnibus title would be displayed at the end of the Omnibus section (disregarding chronological order relative to the titles not in the series), and then it would NOT be displayed with the series in a subsequent section. This is true for the other container types, too. So the code impact to get it to work as intended in the suggestion would go well beyond simply disregarding some type(s) of title. --MartyD 16:44, 29 June 2009 (UTC)

I see. So as the code is currently structured it would not be feasible to include a title in a series, but not use it to determine where to display the series, i.e. what "type" to treat the series as? If not, than my suggestion is not a good one for a quick fix -- I did not intend to propose anything that would require massive rework of the display code. I think that the situation which prompted the initial comment here should eventually be addressed in some way, but it is not, IMO a high priority issue. I think i will create an "artifact" at source forge, just so this isn't forgotten, but mark it a lower than default priority. -DES ^Talk 17:31, 29 June 2009 (UTC)

Unfortunately, yes. What happens is it builds a master set of titles by the author. Each section you see is then rendered, in order, by scanning the master set for applicable titles, displaying those titles, and removing them from the master set. Each section works with a progressively smaller list of remaining undisplayed titles. So a series must be displayed before the non-series sections that could display any of its titles, or it will be rendered with only partial contents (and, secondarily, the titles belonging to the series will be out of chronological order in their respective sections). This could be handled differently using various other approaches, but that's the way it works right now. --MartyD 21:48, 29 June 2009 (UTC)

Patch r2009-05

Patch r2009-05 has been assembled and tested. It will be installed on the live server later tonight. Here is what has been changed by the patch:

• Workaround for Bug 2813351, implementation of Feature Request 2813358 - Fix the verification table and add additional verification sources to the verification list: Bleiler78, OCLC/WorldCat, primary 2 through 5.
• Bug 2803315 - Fix XML errors for poorly formed submissions in recent edits display. Add the date of submission in the pending edits display.
• Feature 2008485 - Re-enabled Chapterbook support on the way to SHORTWORK support. Allowed CHAPTERBOOK contents and title types and hid CHAPTERBOOK contents for CHAPTERBOOK publications.
• Feature 2804561 - Made Series Bibliography display of titles and variants consistent with the Summary Bibliography display.
• Feature 2811692 - Redid display of titles with variants and variant titles in Summary and Series bibliographies per ISFDB:Community_Portal discussions.

Patch installed, preliminary testing looks good. All yours! :) Ahasuerus 02:36, 28 June 2009 (UTC)

Looks good.

• I've already edited a chapterbooks and it stayed a CHAPTERBOOK.
• I've used the new OCLC verification, and i love it.
  • Like the Primary 2-5 also, but haven't used them yet.
  • Haven't tried editing the ref list further -- not much current reason. Although -- LoC as a ref rource?
• The variants in both series and summery displays look good -- as prototyped.
• The recent edits and rejected edits seem to be fixed. Good.
• The time-stamp in pending edits is good. Thanks.

Thanks a lot. Now I'll add a FR or two to USE the added verifications. The fun never ends. -DES ^Talk 05:46, 28 June 2009 (UTC)

Hi all, I've been rather quiet lately (adding to my collection :-), plus "life"), but plan to try and get on top of what's been happening lately as soon as I can. Just wanted to say that what I've noticed so far of the changes I like, especially the user's wiki link after each submission (I'm OK to see it as a mod.), and mod. links to submitter's talk pages & to the current view of pubs. Also, I've just noticed the new vt display & I like it; and I'm looking forward to checking out the chapterbook stuff & series display stuff. ... clarkmci/--j_clark 08:39, 28 June 2009 (UTC)

Welcome back and have fun with Chapterbooks! :) Ahasuerus 02:09, 29 June 2009 (UTC)

Looking good, but I'm now quite keen to see how people use the Chapterbooks. I've already run into other considerations, e.g. Narnia. The changes have allowed me to round up the lost fragments of "The Lion, the Witch and the Wardrobe" and "Prince Caspian" that we had, but it seems clear that these have been fragmented at several different levels for different reading abilities. E.g. The Lion, the Witch and the Wardrobe broken into four Chapterbooks at one level, which are then Boxed back into an Omnibus which I suspect covers the one Novel. Maybe five for Prince Caspian. And Amazon Authors for the fragments don't match the overall Author, and the one I know exists doesn't actually credit the Amazon Author at all. I've not added the Picture Books (which are for an even younger level) but we seem to have a Collection (should be Omnibus?} for some here. BLongley 20:46, 28 June 2009 (UTC)

Please don't judge the capabilities from what I've been doing in the meantime, this is all still very experimental, but it should allow people to highlight the problems. I'm sure I could make those look better by adding shortfiction contents to the Chapterbooks and putting those into the Narnia series instead, for instance. My examples already overlap with the problems of "something republished in several volumes, several different ways" and "title page doesn't actually reflect true authorship", so it's not just chapterbooks. BLongley 20:46, 28 June 2009 (UTC)

Here's an example of a change I've made with the new chapterbook container capability. I've always felt uncomfortable with it being hidden in the shortfiction listings, and besides, there's a novelette with the same title. Now what's the next step? Should I create a content of the same title? If I do, would it be shortfiction? (It's actually a screenplay, but that's not a choice for type.) If so, I'd be back in the same boat with two records under shortfiction with the same name. I think it's better now not having a content. Was this considered when the change was created? Will there be a link to create new chapterbooks from the editing tool menu, or do we have to resort to the workaround of changing the pub type in the new pub edit screen? Thanks for any suggestions. MHHutchins 03:50, 29 June 2009 (UTC)

Chapterbooks are now "container" Publications -- similar to Collections, Anthologies and Omnibuses -- so a Chapterbook Publication needs to have one Chapterbook Title and at least one Shortfiction Titles associated with it. Ahasuerus 04:06, 29 June 2009 (UTC)

I'm not so sure it does. For some fragmented books, like the Narnia Chapter Books, I'm leaning towards leaving them just as Chapterbooks. I could be persuaded to add "(excerpt)" contents, but we can't link excerpts to full titles yet, so we'll be working around by putting them in the same series or suchlike, in which case just putting the Chapterbooks in the series (or a sub-series) might work just as well. Ooh, what a can of worms this is! BLongley 22:07, 29 June 2009 (UTC)

The latter needs to be merged with other identical Titles (if any) just like you would do it with a new Collection. If you don't enter the Shortfiction Title, then there will be no way to follow from the Chapterbook Pub to other appearances of that Shortfiction Title. The good news is that the display logic now hides Chapterbook Titles when displaying Chapterbook Publications just like it hides Collection Titles when displaying Collection Publications.Ahasuerus 04:06, 29 June 2009 (UTC)

As far as the problem with two Titles with the same name goes, I am afraid the last round of changes won't help with that :-( Ahasuerus 04:06, 29 June 2009 (UTC)

P.S. And, of course, we need to update Help to make this clear. Ahasuerus 04:07, 29 June 2009 (UTC)

I've added content to 402521. See what you think. The chapbook is now listed in the chapbooks section, and the screenplay in shortfiction. Since it is at least possible that the screenplay will be included in some later collection or anthology, this seems to me the way to handle such cases. -DES ^Talk 14:42, 29 June 2009 (UTC)

It looks ok, but I'm going to change the screenplay from novelette to shortfiction with no length designation. That's the only way until we come up with other types. Thanks. MHHutchins 17:34, 29 June 2009 (UTC)

I'm not sure that i agree that it is the only way, but it is a plausible method and you are the primary verifier on this item. We should perhaps have a Rules and Standards discussion on how to handle such entries until/unless we create new types. Note that by directly editing the title record, freeform text can be put into the storylen field, so one could put "screenplay" there. However, i don't think anything would display such except the title editor. -DES ^Talk 17:55, 29 June 2009 (UTC)

I've always made any play (teleplay, screenplay, stage play) as SHORTFICTION without a length designation. Giving it a length just seems strange to me. But feel free to bring up a discussion on the Rules page. It would all be made moot if we ever add more types. MHHutchins 18:30, 29 June 2009 (UTC)

I've updated the help on chapterbooks. On the Narnia chapterbooks, the current help discourages entering boxed sets as such if the individual books have separate ISBNs. Do this in thisn case? -DES ^Talk 15:07, 29 June 2009 (UTC)

Current help on boxed sets looks like original help to me, and doesn't seem to match current practice. I know I dislike it as I had to divert into fixing many of the "Chronicles of Narnia" Omnibuses to reflect their actual contents - there's two-book, three-book and four-book versions as well as the typical seven-book ones that most were lumped under, as well as this set that only covers one novel (as best I can tell). I remember a discussion on recording the printing numbers of the books in a boxed-set at one point that seemed to go a bit too far, but keeping links to original Novel content titles seems wise whether it's bound as one volume or just boxed. BLongley 20:08, 29 June 2009 (UTC)

I like the idea in the current help that a boxed set as such is not usually worth recording, but I haven't dealt with many of these and perhaps there are good reasons why practice has not been following the help, if in fact that is what most people are doing. At some point, in our copious free time, we should probably either codify practice and update the help, or agree to stick to the help and reform practice. -DES ^Talk 20:41, 29 June 2009 (UTC)

Well, when a book is desperately unavailable it's nice to know it's still available in an Omnibus, the same might go for Boxed sets. I can't think of an example offhand, but some special Chapterbooks seem to be only available as an addition to a Collection or Anthology or a Novel, in the same slip-case. It would be a loss to remove such to notes alone. BLongley 21:54, 29 June 2009 (UTC)

The help says not to record boxed sets when the individual books have ISBNs, and presumably are available separately. When not available separately, i would probably record the boxed set as an omnibus or collection or anthology, ignoring the physical separation of the parts, treating them as if the slipcover were a binding that joined them all. But perhaps this would be a mistake. -DES ^Talk 22:30, 29 June 2009 (UTC)

I'm not sure why you're highlighting when the individual books have ISBNs. That has nothing to do with availability. If I cannot find a reasonably priced edition of a title, or find it at all as a stand-alone publication, I'll look for it in an Omnibus. Will settle for "as part of a boxed set". Magazine publication maybe. (I've not yet accepted an ebook substitute, but some will.) I know I've been annoyed when I've tried to track down a particular piece of shortfiction, only to find that I already own it in another Collection or Anthology that somebody has been too lazy to add the contents to. Why hide long fiction away in notes? If I want something, I want to know where to find it. That's surely what ISFDB is for? BLongley 23:05, 29 June 2009 (UTC)

What that really indicates IMO is "the individual volumes were published separately, and the boxed set is not a separate thing, but merely a form of packaging". However if the boxed set has a separate ISBN, or is sold as such in the used market, perhaps recording both is better. If the individual volumes were not sold separately, and thus probably don't have ISBNs, then i would record the boxed set as an integral item, like an anthology or omnibus, and would record the volumes as contents items of that title. i never said they would be hidden in notes, any more than the novels of an omnibus, or the contents of a collection are hidden in notes. If full data is available, they are present in content records. (of course I do create collection and anthology stubs from secondary sources, which sometimes don't list contents, but these are never primary verified when in that state, and i'll add contents if I find the data. I've filled in a good many anthology records with contents from library copies.) I admit that I could be mistaken on boxed sets. -DES ^Talk 23:17, 29 June 2009 (UTC)

Keeping links to Chapterbook contents may be less wise, and certainly looks cluttered - but for Chapterbooks like those where there's no sensible "Shortfiction" content to create, it might be the best way. Some are available for Amazon Look-Inside but they seem to show Chapter titles which may or may not match real chapters in the novel - and I really think we don't want to go down to that level. And it might be that they overlap - I'm afraid I don't have real examples to compare, but I can imagine such a book being broken-up by character viewpoints (Susan, Peter, Edmund, Lucy) with some overlap when multiple characters are present, or just to make such a viewpoint consistent overall. Ah well, that's why we're experimenting. BLongley 20:08, 29 June 2009 (UTC)

If I were entering one of these i would probably create a work of short fiction to be a content item, much as a new shortfiction title record is created when we record an excerpt of a forthcoming book in another book. Oh what a field for "based on" :) -- dream on. But I don't say that that is the one-true-way. I agree that I wouldn't index cahpter titles, but than we don't normally in novels or in those works of short fiction that have named chapters. -DES ^Talk 20:41, 29 June 2009 (UTC)

It might be that we want to create "(excerpt)" content titles for such rather than give them the overall name - but this is one of the things we're experimenting with. Chapterbook titles don't have to match content titles now - so we could change all those Stephen Eley "Escape Pod" entries back to their official titles as Chapterbooks and add the shortfiction contents properly. But people seem to like the Magazine workaround. Note that Magazine entries, with the EDITOR records rather than Title, actually exhibit a lot of the problems we would call "bugs" on the book side. BLongley 21:54, 29 June 2009 (UTC)

I never liked the magazine workaround, and would have undone it if I had more support, even in the previous "broken" state of chapterbooks. I would favor undoing it now. I think we do want to create shortfiction contents for most if not all existing chapter books pubs. -DES ^Talk 22:30, 29 June 2009 (UTC)

• Sub-thread moved to ISFDB:Proposed Interface Changes#Add publication to this title, from a shortfiction work -DES ^Talk 20:59, 30 June 2009 (UTC)

(Unindent) Perhaps it's time to move some of these discussions elsewhere? I don't think anyone is actually complaining about r2009-05, but it's certainly sparked some other discussions! BLongley 20:39, 30 June 2009 (UTC)

Did I find a bug?

Just now I attempted to clone an entry and because of some problems in the past I try to to be more careful, I was paying close attention to what I was doing. What happened was I clicked the "Clone this pub" button and got the "Edit this pub" window! The "Clone" also changed color so I now I clicked it. I don't think I'm crazy, I'm sure this is what happened.Don Erikson 18:06, 28 June 2009 (UTC)

Hover your mouse over 'Clone this pub'. Look at the Status Bar at the bottom of your web browser (If it's not there you can usually turn it on with the 'view menu' in most browsers IIRC). Does your status bar show "clonepub.cgi" followed by a number? Do the same test over 'Edit this Pub', Do you see "editpub.cgi" followed by the same number? Lastly - What browser are you using? Kevin 18:54, 28 June 2009 (UTC)

List of (hopefully) simple features for Approval

Feature Request 2813441

Summary: Statistics should react to additional verifications (DES)

Description: The statistics page should include in its count of verified pubs any pub with any of the "primary" verifications set: #1, transient, or #s 2-5. The statistics page should also include a separate count of pubs with at least one secondary verification flag set, and one of pubs with any verification flag set, primary or secondary.

Comments: Seems logical and simple enough to implement. The only concern that I have is that the Statistics page already takes a few seconds to compile, so making the logic more complex will put an extra load on the server, but it should be fairly marginal. Ahasuerus 03:50, 29 June 2009 (UTC)

Disposition: No objections raised, moved to "Approved". Any volunteers? Ahasuerus 22:24, 30 June 2009 (UTC)

Feature Request 2813434

Summary: Warn of additional verifications (DES)

Description: If one of the "primary" verifications other than #1 is set, a moderator should get the same warning when a proposed pub edit is displayed as for primary #1. This should include Primary (transient). If more than one primary verification is set, the warning should include the (linked) names of all verifiers. If a non-primary verification is set, there should be a different (smaller) warning displayed to the moderator.

Comments: Seems useful and straightforward to implement. No additional concerns that I can see, although there may be some minor questions about the implementation specifics. Ahasuerus 03:50, 29 June 2009 (UTC)

Not only do I like it, but this should be short tracked now that we have Primary 2-5. Adding Transient Primary to that list would be a bonus, and adding the secondary sources would be a double bonus. Kevin 00:47, 30 June 2009 (UTC)

Seems trivial (assuming that we don't go for the big fix where we make sure people are verifying by ref_id rather than position in the ref list), but the number of primary, primary transient, and secondary sources should be fairly settled before doing this. Or is everybody happy with what we've got now, they just haven't said so? BLongley 19:28, 30 June 2009 (UTC)

The number of primary verifications looks reasonable for now, but it's hard to tell what we may decide once we start using the new verification options. Secondaries are a different story as we'll probably never stop adding to them. With the list getting as long as it is, we may want to consider not displaying some (or all) verification sources that are not marked as "verified". But that's another feature request. Ahasuerus 03:32, 1 July 2009 (UTC)

And what should the smaller warning look like? Do we need the names of the people that Tuck/Currey/other-verified it? Do we want to list the sources it's been verified against, or just say "a secondary source" (or give the number of secondary sources)? BLongley 19:28, 30 June 2009 (UTC)

I was thinking that we would basically recreate the Publication-specific verification list except that we would omit any unverified references. It's easy enough to do and gives the approving moderator all the information he could possibly need. Ahasuerus 03:35, 1 July 2009 (UTC)

Primary (Transient), as originally designed, was so that verifiers wouldn't be questioned about pubs they no longer had access to, so I'd normally recommend that the names of such verifiers not be displayed. But as some people have been using it for a second Primary it's arguable that we should list them. Maybe non-linkable credits though so we're not encouraging botherations? BLongley 19:28, 30 June 2009 (UTC)

It might also be nice to give "Primary (Transient)" Verifiers a list of their verifications in case they want to move them to a non-transient version. But there's privacy issues in that, their actual user_id number is fairly secret. But so long as there aren't too many requesters, I could deal with those off-line for people that want such and are willing to trust me with their user_id: or we can develop a "My Verifications" display, but that would definitely warrant another feature request! BLongley 19:28, 30 June 2009 (UTC)

FR# 2813437 My verifications has already been logged. This FR was logged at about the same time, both in reaction to the newly available verification types. -DES ^Talk 20:21, 30 June 2009 (UTC)

Minor issues, but I think it's probably best to do a quick poll on the options, as I can see many. And there's the option to make it a slightly bigger change, where reference sources can be flagged as Primary or Secondary to cope with new additions - but that could be another feature request. BLongley 19:28, 30 June 2009 (UTC)

I think it's best to make it a separate feature request. "Easy does it" and all that :) Ahasuerus 03:32, 1 July 2009 (UTC)

That would make sense, IMO. There was discussion but I don't think a formal FR, of adding code to display the reference URL for each line in the verification matrix. Currently this URL is either for the reference source itself, or for an ISFDB wiki help page that describes and/or explains how to use the reference source. -DES ^Talk 20:21, 30 June 2009 (UTC)

That's Feature request 2813354. Ahasuerus 03:32, 1 July 2009 (UTC)

(Aside: does anyone remember/know/have a good guess as to why unverifying a pub gives a "Need to update record for ref=1" message and just resets "ver_status" to 0? I haven't found the point of that column yet.) BLongley 19:28, 30 June 2009 (UTC)

Implementation issues

As to what the warning for secondary verifications should look like, I think it should ideally list the sources verified against, as this would indicate the kind of data that has been checked and shouldn't be changed too lightly. However, since we now have links from the mod display to the pub, a mod could follow that link to find out exactly what sources have been verified against, and by whom. Who the verifier is may matter, as some editors have a reputation for carefully checking sources, but again this can be seen on the pub display. The main way it matters is that when the verifier is the same as the submitter, a mod usually assumes that changes are not treading on a verification improperly. So if there is only one UserID in the verification list it might be well to include it in the warning. -DES ^Talk 20:21, 30 June 2009 (UTC)

As to how Primary (Transient) has been used, I for one have been using it largely in three kinds of cases. 1) On Library books. While I don't have guaranteed future access to these, I could in many cases find them again. 2) Books borrowed from friends. These may or may not be available for re-checking. 3) As a hack for Primary 2 when we didn't have such a thing. These I would convert to primary 2 (or N) when I ran into them, or if My Verifications was implemented. But even on cases 1 & 2, even when i don't have re-access handy, i do have a good memory, particularly when stimulated by cues, such as the record I verified. I might, but do not guarantee to, be able to answer at least some questions about such books from memory. So I would have no problem having my "Primary (Transient)" verifications listed by name for a mod. -DES ^Talk 20:21, 30 June 2009 (UTC)

As I wrote in response to Bill's comments above, I think that replicating the Publication-specific verification table while omitting all unverified rows would be the easiest and least confusing option. There are many possible permutations of primary and secondary verifications and its best to provide the moderator with a complete picture rather than try to guess what may or may not be useful under different circumstances. Ahasuerus 03:38, 1 July 2009 (UTC)

Feature Request 2809620

Summary: Change new Contents default for Omnibuses and Non-fiction (Ahasuerus/Bill)

Description: Change new Contents default values for Omnibuses and Non-fiction. It should be Novel for Omnibuses and Essay for Non-fiction.

Comments: Seems logical now that the main default has been changed from Anthology to Shortfiction. Any issues with it? Ahasuerus 04:20, 29 June 2009 (UTC)

I've no issues with these two. I'd welcome comments on other types of container titles: e.g. if MAGAZINE entries usually start with an Editorial, then one ESSAY first and then SHORTFICTION for the rest might be more appropriate than 9 SHORTFICTION blanks. We might as well ask if the number of blank entries is appropriate too, rather than keep changing edit/newpub: I've NEVER had any sort of publication with exactly 9 Shortfiction, 3 Reviews, 2 Interviews and no Essays in. BLongley 19:44, 30 June 2009 (UTC)

Some magazines have a leading editorial, but many (most?) reprint magazines don't. I think it's somewhat safer to have all Contents entries in Magazines defaulted to SHORTFICTION to be consistent. As far as the numbers go, well, I suppose we could check out current stats, but additional Review and Interview placeholders seem pretty harmless even if they are blank half the the time. Ahasuerus 22:11, 30 June 2009 (UTC)

I disagree (On additional is harmless). Every additional form area you add complicates the screen, causes the editor to scroll more, increases the likelihood that they may begin an edit and abandon it, etc etc. I recommend that we 'Reduce' the number of entries... probably Three contents items, and 1 review, and 1 interview. Just enough to show the capabilities of the form. Kevin 02:19, 1 July 2009 (UTC)

I don't have a particularly strong opinion one way or the other, but we'd need a separate Feature Request to change the number of placeholders. This one only affects Omnibuses and Non-fiction books. Ahasuerus 03:45, 1 July 2009 (UTC)

But don't spend too long figuring out every nuance, these look like no-brainers to me and I'd happily do them for now and tell people they missed the boat this time if there's too much dithering. BLongley 19:44, 30 June 2009 (UTC)

All yours -- already assigned on Sourceforge! :) Ahasuerus 22:11, 30 June 2009 (UTC)

OK, will look at tomorrow, unless Real-Life code-implementations go horribly wrong and I'm stuck in a poorly air-conditioned space out of hours with no support... hang on, that's the same as here, isn't it? ;-) BLongley 22:37, 30 June 2009 (UTC)

I think I jinxed myself. I did indeed end up stuck at work in a poorly air-conditioned space out of hours with no support, after an imperfect implementation. :-( Still, this was simple and is committed now. BLongley 19:51, 1 July 2009 (UTC)

I think we DO need a review of the number of contents - 10 Novel Omnibuses are so rare that the default looks ridiculous to me. (Even using it for boxed sets it would be over the top.) Kevin, please make a suggested Feature Request covering all title types. BLongley 19:51, 1 July 2009 (UTC)

Feature Request 2809878

Summary: Show Reviews of VTs in the Title screen (Ahasuerus based on a Wiki discussion)

Description: Currently, the Title screen displays all linked Reviews for the Title. As per Wiki discussions, we also want it to display any Reviews of the Variant Titles associated with this Title.

Comments: This was requested during the Wiki discussion which decided to link Review records to the reviewed VTs rather than their canonical Title records. Seems needed and moderately urgent. Ahasuerus 04:25, 29 June 2009 (UTC)

May I work on this one? --Roglo 21:26, 29 June 2009 (UTC)

Feel free, but please document what the plan is. I don't remember a decision to link to VTs rather than canonical title: but I think it's clear that the canonical title should show links to all reviews, VTs should link to the reviews of the VT. The next complication is whether they should link to the reviewer's canonical review record or the variant review record. Or both. For instance, "Fred Patten" or "Frederick Patten", or "Thomas A. Easton" or "Tom Easton"? BLongley 22:24, 29 June 2009 (UTC)

Actually, the original idea behind this list was to identify which features should be "approved" rather than to assign them to individual developers, but if the feature looks non-controversial, then it might as well be implemented right away. Assigned in Sourceforge.

As far as Bill's request for "documenting the plan" goes, we probably need a separate discussion for that. This feature request is limited to displaying all reviews of associated VTs on the main Title's page, which should be straightforward and apparently won't depend on any other decisions we may make. Ahasuerus 05:39, 30 June 2009 (UTC)

Thank you for the assignment. Yes, the plan for now is to leave Reviews of the VT in the VT's bibliography just the way they are listed there now, but to show them also (and in the same way) in the canonical title's biblio. An example (a new classic) is: Black Man which has a review of the canonical title in Interzone, but was reviewed as Thirteen by Richard K. Morgan in F&SF. Both should be listed in the Black Man's biblio. This change does not imply a new policy on linking reviews. Any changes to how a review reference looks would be new Feature Requests, and certainly there are things to discuss later. --Roglo 16:02, 30 June 2009 (UTC)

Excellent, thanks! :) Ahasuerus 18:02, 30 June 2009 (UTC)

OK, scope is clear now. I'd seriously consider fixing the reviewer link (I hate finding myself on a "Pseudonym. See:" page at times) but that should probably be one big feature request, broken down into smaller steps as people decide which screens annoy them that way. BLongley 19:56, 30 June 2009 (UTC)

Now that Review Links can be created directly (The lexical match is dead! Sometimes), we should probably check how people are using them, as there's no actual restriction on linking a review to Variant or Canonical title. But that's a bit of research before yet another Feature Request. BLongley 19:56, 30 June 2009 (UTC)

Searching for pubtype

In the Advanced Search Publication section, one of the things you can search on is "Ptype". I assumed this would be the publication type, and I could use it to find all "chapterbooks", or a significant number of them (even the first 100). However, it seems to be actually searching on the "binding field". Is this a bug, or is it working as designed and I just misunderstood it? Would it be reasonable to be able to search on both binding and type from this screen? Would a better description than "Ptype" be a good idea? Do we have a bug report or a feature request here, or perhaps both? -DES ^Talk 18:01, 29 June 2009 (UTC)

Ptype is indeed the binding, Ctype would be what you want. However, for properly formed Chapterbooks the title Ttype and pub Ctype should match, so you can do a title search for "Title Type" of CHAPTERBOOK. For improperly formed ones, what are you searching for? Pub IDs 332, 333, 334, 335, 336, 507, 688, 276796 are the ones in the first thousand pubs I looked at, if you're just looking for a few examples. BLongley 19:09, 29 June 2009 (UTC)

I was actually hoping to generate a comprehensive list of improperly formed ones, to start fixing them. I'm not sure if there are many routine reasons to search by pubtype, but it would probably be useful now and then. If we are to have a search by binding, it would probably be better if the dropdown said "binding" or "format" (those being what the editing screen and help call this field) or something more intuitive than "Ptype". -DES ^Talk 19:27, 29 June 2009 (UTC)

Changes to Advanced Pub Search are a bit back-logged at the moment, due to performance concerns. But I can see benefits to searching by Ctype as well as Ptype, and yes we should make it clearer what they mean. BLongley 19:46, 29 June 2009 (UTC)

For the moment, I can post a longer list of Ctype=CHAPTERBOOK pubs if you like, or send you the whole lot (1335 of them) as of last but one backup (before we started playing with them again). I don't really want to make any judgements on whether they're improperly formed though - some of the effects accomplished while the software was broken actually work for some people. But we should definitely look at a few more examples, e.g. where they've been used for audiobooks or ebooks. BLongley 19:46, 29 June 2009 (UTC)

Please do post or send (Siegel AT acm [dot] org) the list. (If you send, I will post, perhaps on a userspace page, and in sections) When i say ill-formed, I mean purely in a technical sense, pubs where Ctype != Ttype. My guess is that most of these should be edited in some way to take account of the revised/restored functionality of CHAPTERBOOKs, and to prepare them for the further change into SHORTWORK or whatever we finally call it. But I don't propose mass conversion without a human looking at and judging each individual example. -DES ^Talk 20:03, 29 June 2009 (UTC)

I have myself created new CHAPTERBOOKs for ebooks since the recent revisions was installed, for example The Light Princess.

I am aware that changes to advanced search are awaiting decisions on how to improve performance, and prevent changes from harming performance. I just wanted to register this change as desired, sooner or later (although i would think the text in the dropdown could be changed without impacting anything else pretty easily). Thanks for your response. -DES ^Talk 20:03, 29 June 2009 (UTC)

r2009-06 is live

Patch r2009-06 has been installed on the live server. Only one of the two implemented feature is visible to the users, namely Feature Request 2809517 (Link REVIEW Titles to the reviewed Titles), the other one has no impact (or at least it had better not!) Ahasuerus 04:58, 1 July 2009 (UTC)

VT display bug

FYI, I have found what appears to be a bug. Here is how I entered it in Sourceforge:

Bug: 2815548

Title: Series VTs are not always displayed in Author biblios

Description: VTs for Titles that belong to Series are not always displayed in Author and Series bibliographies. For example, two of Dave Wolverton's Titles, "The Golden Queen" and "Beyond the Gate", have been published both as by Dave Wolverton and as by Dave Farland, but the Farland VT doesn't appear either in the Wolverton Author biblio or in the Series biblio.

Ahasuerus 03:16, 2 July 2009 (UTC)

It turned out to be an ancient data problem affecting 4 records, 2 in Dave Wolverton's biblio and 2 in Heinlein's biblio. All fixed now thanks to Marty! Bug 2815548 has been closed. Ahasuerus 04:53, 4 July 2009 (UTC)

Title Deletions and Votes

If you have an opinion about how the deletion of a title should interact with an editor's votes for the title, please make your voice heard at ISFDB:Proposed_Interface_Changes#Title_Deletions_and_Votes:_Two_Questions. --MartyD 13:17, 2 July 2009 (UTC)

Tony Hillerman

See ISFDB:Help desk#Tony Hillerman. I think that Tony Hillerman's novels should be OUT, but before deleting them, would like to know if there is an appropriate place to save the data we have? -DES ^Talk 16:23, 3 July 2009 (UTC)

Ahasuerus created a biblioholics site for such. BLongley 18:24, 3 July 2009 (UTC)

The original plan (as of a few months ago) was to create a mini-spider which would capture all Publications for the about-to-be-deleted Author's Titles, but I haven't had a chance to work on it with all the other stuff going on. Ahasuerus 04:57, 4 July 2009 (UTC)

"New Messages" alert / link to Talk page in ISFDB

If you have opinions about how a user should be notified of new Talk while within the ISFDB, please make your voice heard at ISFDB:Proposed_Interface_Changes#FR_.232805588_--_.22new_talk.22_alert_within_ISFDB. --MartyD 13:40, 4 July 2009 (UTC)

Patch r2009-07

Patch r2009-07 has been assembled and tested. It will be installed on the live server shortly. The following changes will be made:

• Features 2803286 and 2800737. Various Minor Navbar fixes, updates, and improvements as per Wiki discussion.
• Feature 2809620. Change new Contents default values for Omnibuses (to Novels) and Non-fiction (to Essay)
• Feature 2809878. Show Reviews of VTs in the canonical Title screen.
• Bug 2815724. Fixed the Python error in "My Votes" if a voted-for title has been deleted.

Please report any issue that you may find here. Thanks! Ahasuerus 23:21, 4 July 2009 (UTC)

When I'm bored

After I completed adding covers to all issues of Startling Stories yesterday, I noticed that the monthly series of banners lacks some months. So, here's my suggestion: with background #1 and with background #2. Both background images have a subtle fading on the right side towards the dark blue used in the area next to the banner. However, since you used the same background for most banners it would be no big deal to apply it here. Detailed picture credits (from left to right):

• Fall 1943, Earle Bergey.
• Winter 1946, Earle Bergey.
• July 1939, Howard V. Brown.
• January 1939, unknown.
• May 1947, Earle Bergey.
• Spring 1954, Alex Schomburg.
• Summer 1945, Earle Bergey.
• September 1949, Earle Bergey.

If you like it feel free to use it. --Phileas 16:57, 5 July 2009 (UTC)

Great job. I prefer the first one, but think either should go into monthly rotation with the other banners. I'm glad they (whoever does it) changed to the current one. The January banner has been around so long and that peach with popeyes was starting to bug me! MHHutchins 18:50, 5 July 2009 (UTC)

Al is our art-meister :) Ahasuerus 19:05, 5 July 2009 (UTC)

Since the banner is picked up from the style-sheet, it's currently updated by hand. I'll look into picking it up from a generic name (like IsfdbBanner.jpg), and have a cron job that rotates the monthly banner into the generic named file. Alvonruff 18:56, 6 July 2009 (UTC)

So is someone going to check this in here? I can't recall how to do binary files in CVS offhand, and don't think I've got enough access to credit the author properly. BLongley 18:41, 6 July 2009 (UTC)

Awesome. I kind of like the background for a change-up, but can send you a photoshop blank with the current background if you like. Alvonruff 18:49, 6 July 2009 (UTC)

Made this edit yesterday, but closed the browser without to confirming the "maths question". So here we go again... If the background is fine with you it's fine with me too. Just offered you to replace it if you want to have them all the same background. The background images are unaltered Hubble shots - copyright free as that page says. I after seeing the pic on the banner page I noticed that stupid me uploaded the wrong files. The levels aren't adjusted and the background alignment on the left is a little off - minor stuff but still... I know what you're thinking and you're right, I keep getting 100% on this ;). However, here are the final versions I intended to upload in the first place: [1] / [2]. Just in case you do like archiving stuff you can get the Photoshop file here (or alternatively here). --Phileas 17:18, 8 July 2009 (UTC)

I like that idea with the cron daemon. As long as it doesn't change every minute. --Phileas 17:18, 8 July 2009 (UTC)

Don Westlake

Any reason to think Don Westlake, with one story credited is not the same person as Donald E. Westlake? -- Dave (davecat) 23:51, 5 July 2009 (UTC)

The time period is correct, as this is the era when Donald E. Westlake was writing SF, some of it published in Analog. Westlake was known to friends as "Don", I understand. That maked ity plausible, but not IMO proven. I can't find any online bibliographies of Donald E. Westlake that include his uncollected short fiction. -DES ^Talk 00:23, 6 July 2009 (UTC)

I spoke too soon. this site lists "Look Before You Leap" (May 1962, Analog SF) as one of Donald E. Westlake's works. So the answer seems to be "Yes!" -DES ^Talk 00:29, 6 July 2009 (UTC)

This second site confirms the first. -DES ^Talk 00:32, 6 July 2009 (UTC)

I have created the pseudonym relationship. -DES ^Talk 03:22, 6 July 2009 (UTC)

Thanks! -- Dave (davecat) 14:02, 7 July 2009 (UTC)

Pseudonyms authors don't want revealed

There are some cases where an author (or group of co-authors) strongly prefers to keep a pseudonym private, and has taken steps to avoid the "real name" becoming public. In such a case, should we enter the actual names and thus reveal this info?

In particular I am thinking of an SF novel written by two authors under a collective pseudonym. Nowhere on the book, (which i own) is the actual authorship indicated. Indeed a faked bio for the "author" is included in the book. I understand from a friend, who worked in the publishing industry, and who knew one of the authors personally, that the collaboration did not go well (although IMO the result was good), and left bad feelings between the authors, and that at least in part for that reason, don't want their association made public. But I recently notice that the ISFDB correctly identifies the actual co-authors in this case. Should it? -DES ^Talk 03:21, 6 July 2009 (UTC)

If it's in the db and you confirm that it's a true pseudonym, I don't believe it should be dis-associated from the true authors. The SF community is not as close-knit as it once was, but it's still hard to contain such information once it's known by more than one person. I'm not sure what you mean by "taken steps to avoid" the name becoming public knowledge. Stephen King thought he'd covered his tracks about the Richard Bachman pseudonym, only getting tripped up by the papers filing the copyright requiring the name of the true author. I guess that can be avoided by copyrighting under a corporate name, but then the corporation papers might lead back to the author as well. MHHutchins 03:47, 6 July 2009 (UTC)

I find that there are different degrees of "prefer[s] to keep a pseudonym private". For example, if I recall correctly, Christopher Pike didn't want his legal name to be revealed in part because he was a hugely popular teen author while his kids were still in middle/high school, but he didn't seem to mind when adult-oriented books (encyclopedias etc) mentioned his real name. Lawrence Evans, to use another example, tried to keep his "Watt-Evans" persona separate from his (science fiction/tie-ins) "Nathan Archer" persona even on Usenet, but I don't know whether he feels strongly about it these days.

As a general rule, I think we should approximate the Wikipedia standard, i.e. use whatever information is publicly available without doing "original research" in this area or relying on undisclosed information. For example, it has been known for close to 20 years that Ron Goulart and perhaps others played an active role in the creation of the Tek (aka Jake Cardigan) series even though the books credited William Shatner alone (reportedly because the suits pointed out that celebrity books sell better if there is no collaborator.) Last year, Shatner explicitly credited Goulart as the co-author of TekLab, the third book in the series (see p. 246 of Shatner's autobiography Up Till Now), so I believe we can VT it now, but I would be hesitant to do so without a reliable source. Conversely, once a reliable source has been identified, I wouldn't remove the VT as long as the source isn't proven to be wrong. Ahasuerus 05:22, 6 July 2009 (UTC)

Fair enough. Just wanted to raise the issue. The case from the past, now public, that comes to my mind is that of the pseudonym James Tiptree, Jr., aka Raccoona Sheldon, aka Alice Bradley Sheldon. Still even there, (or maybe particularly there since "Tiptree's" "real" identity had been a subject of discussion) once the facts were out, they spread widely and rapidly. -DES ^Talk 14:16, 6 July 2009 (UTC)

In one case a pseudonymous author had raved about her agent. I looked over the list of authors the agent represented and spotted the real name based on the style of writing. I e-mailed the real-person who confirmed the pseudonym was hers but was also sad/surprised she'd been found out. I thought about it and decided to not enter that one as a pseudonym in ISFDB. I'd confirmed name name from a reliable source but still considered it to be her private thing. The pseudonym looks like a real name, complete with bio that more or less matches the real person. I discovered the name was a pseudonym as I wanted to fill out the ISFDB author record and Googled it up. When I found the person had not set up a single web site or page I took that as a clue that the name was a pseudonym and dug harder. --Marc Kupper|talk 07:55, 7 July 2009 (UTC)

I think you were right not to enter that one. With no published disclosure, and the author's wishes clear, I think we are better not to be the first to publish such info. -DES ^Talk 13:00, 7 July 2009 (UTC)

I agree that we shouldn't be the first ones to publish this information. Also, keep in mind that Web pages are set up for pseudonymous authors every day now. It seems to be a part of the services provided by certain publishers, especially in the urban fantasy/paranormal romance field, and we all know how many pseudonyms they use in that corner of the woods. Ahasuerus 13:39, 7 July 2009 (UTC)

UK Wildside?

The notes to a pub of The Moon People say "Wildside is a print-on-demand paperback publisher in the UK." The PoD Wildside I know is a US operation, and that is the one described in the Wikipedia article linked to from our Wildside Press record. Is there a different UK firm by this name? a UK branch of the US firm? Or is this note in error? The pub isn't verified, and the recent edit to it (which is how I happened to notice this) did not change the note, so i don't know who to ask in particular about this. -DES ^Talk 20:08, 6 July 2009 (UTC)

I'm not aware of a UK version, they all seem US to me. Typo? (Although K and S are a long way apart on MY keyboard.) BLongley 21:43, 6 July 2009 (UTC)

My guess is more "thinko" than typo -- someone saw soemthign that made him or her think that Wildside was a UK outfit, or misremembered soemthing. But sicn the same note links to the website for the US Wildside we both knew of, and that site gives their Maryland address, i am going to change the note. -DES ^Talk 22:16, 6 July 2009 (UTC)

Chapterbook issues

I have been doing a little fixing of existing chapterbook publications without a chapterbook title record, and I have noticed two things. One is a possible "gotcha" but not I think a bug, the other I think is a bug.

• In fixing an existing chapterbook publication the usual fix is to add a content (title) record of type chapterbook so that each pub contains a shortfiction title and a chapterbook title, often with the same name. However, in doing this one must be quite careful to keep track of which titles have been "fixed". Otherwise it is all too easy to add the chapterbook title record twice. If this is done there is no easy way forward, as the chapterbook title record is hidden even in edit mode, and can not be touched by remove titles from pub. So far the only solution i have found is to create a fresh, new record with the correct contents, and to delete the offending record, now a duplicate. I think this is probably not a bug per se, but anyone fixing existing chapterbook pubs should watch out for it. This is a particular problem when there are multiple chapterbook pubs of the same title -- I hit this on A Christmas Carol in Prose by Dickens.
• When a chapterbook publication has been fixed, a user can go from the author's biblio page to a chapterbook title, which will display a list of publications, and from there to any one of the pubs. But from one of the pubs, the "title reference" link goes to the work of shortfiction, not to the chapterbook title record. This is not consistent with how collections or anthologies with multiple publications work, even if there is a "title story", that is a work of fiction with the same title as the publication. I think this is a bug.

Other than these two issues I am finding the new chapterbook support pretty good, and wait eagerly for the further fix that will change the name, and provide an "Add New ShortWork" (or whatever) link on the nav bar. -DES ^Talk 21:26, 6 July 2009 (UTC)

There are other issues - e.g. "Merge Titles" still offers you the chance to merge Chapterbooks with their Shortfiction contents, even though we've separated them elsewhere. If we go forward, then I hope that we'll eventually fix Shortfiction that has no link to a title. But experiment (fairly safely, as we should be able to undo any errors now) and we should be able to summarise the good points and the bad points in a week or two, with examples, and go for the next step. BLongley 21:39, 6 July 2009 (UTC)

"Merge Titles" helpfully lists all kinds of Title Types as possible duplicates. At some point we may want to fine tune the matching logic so that it wouldn't think that POEMS and NOVELS are possible duplicates. Ahasuerus

Yep, that needs a look at some point. BLongley 22:26, 6 July 2009 (UTC)

As far as "hiding" matching container Titles in Pub Edit and Title Remove goes, well, the standard workaround is to temporarily change the Pub Type to a non-container type, e.g. Novel, which lets you see all Contents level Titles. However, this raises a larger question: although hiding matching container Titles is a good think when displaying container Pubs to our casual users, is it really useful when editing Pubs and removing Titles? Ahasuerus 21:58, 6 July 2009 (UTC)

It would be nice if there were a button or link in the edit form "Show normally hidden contents". This would only be used when fixing a problem, in 99% of cases it would not be used, but it would save some work when it was used, and save a title being in an incorrect state briefly due to the change -- it would be awkward if an editor's computer crashed or something just after he had changed Again, Dangerous Visions to a POEM temporarily. Remove titles has similar issues, plus the known problem that remove won't remove only one of two titles with matching names and type. -DES ^Talk 22:35, 6 July 2009 (UTC)

When we've got it right, hiding the content title that will match with the container title is good. When it's wrong, we get headaches. I'm not sure all Mods are clear on how to fix things, especially when we've moved off default NOVEL and need at least two edits to get things straight. BLongley 22:26, 6 July 2009 (UTC)

I have often been offered the option to merge a collection with its title story. I don't take the offer. And from the "show titles" page one can merge things that don't even have matching titles. One generally should refrain, of course. It might be a good idea if the "Find duplicates" logic did not offer to merge contains and contents -- merging a novel or shortfiction record with a collection or omnibus is pretty much never the right thing to do. Once in a while merging a shortfiction title with a novel is correct -- when it turns out that they are the same work, entered differently. I've had this happen. Ditto for a merge of an omnibus and a collection. But anyway, as far as merges go, there is no issue for chapterbooks that there isn't also for anthologies and collections. -DES ^Talk 22:11, 6 July 2009 (UTC)

I've added to source forge:

• FR #2817687 (Rrefine "check for duplicates" logic -- types) -DES ^Talk 22:47, 6 July 2009 (UTC)
• FR #2817691 (Show hidden contents during edit) -DES ^Talk 23:01, 6 July 2009 (UTC)
• FR #2817693 (Allow removal of container title from pub) -DES ^Talk 23:10, 6 July 2009 (UTC)
• Bug #2817694 (Chaptebook title link is wrong) -DES ^Talk 23:16, 6 July 2009 (UTC)

(Inindent) I mentioned above that it could be hard to tell if a given chapterbook pub included (pointed to) a CHAPTERBOOK title record or not. It is a kludge, but I have found out that the clone tool displays container records including chapterbook titles. So when faces with a chapterbook pub, do a clone (which there is no intention of submitting) and look to see if there is a CHAPTERBOOK title record in the contents list displayed by the clone tool. I'm finding this workaround useful. -DES ^Talk 15:27, 9 July 2009 (UTC)

Clever! :) Ahasuerus 18:48, 9 July 2009 (UTC)

Thanks. I discovered it by accident. As I've been going through ISFDB:Chapterbook cleanup, I've been checking the chapterbooks against OCLC, when possible. In a number of cases I've found additional editions (HC vs TP; signed vs unsigned; etc) and used clone to create records for them. It was in doing this that I noticed the above property of the clone tool. -DES ^Talk 19:37, 9 July 2009 (UTC)

BTW, I invite others to join in going through a page or two of ISFDB:Chapterbook cleanup if you want something useful but fairly routine to do for a bit. -DES ^Talk 19:37, 9 July 2009 (UTC)

I've been looking at titles like The Reluctant Dragon where I have some Primary reference. Interesting stuff, and the clean-up gets complex. That's one where we need to work on Shortfiction versus "Excerpt" as separate from Chapterbooks, but that's still not always the ideal solution IMO and some things may still be left as "Chapterbook" alone more usefully. The experiment continues! BLongley 21:03, 9 July 2009 (UTC)

I must be missing something. I don't see what is particularly complex about that example. -DES ^Talk 16:11, 13 July 2009 (UTC)

That part has been cleared up now, but there's also The Reluctant Dragon (excerpt). It seems (but I haven't got copies to compare side by side) that in some cases people are recording "The Reluctant Dragon" as an excerpt from "Dream Days" (apparently it was a chapter in that) rather than as a separate title. If they are the same text, then presumably we should have one title or the other only. BLongley 18:14, 13 July 2009 (UTC)

I also don't see when it ever makes sense to have "a Chapterbook alone" if you mean without any shortfiction (or essay) content records. This seems to me as useful as an anthology with no contents (acceptable only as a placeholder until contents are entered) or a NOVEL publication with no NOVEL title record (never acceptable). What am i missing? -DES ^Talk 16:11, 13 July 2009 (UTC)

The Novel is a special case, where we don't have a NOVEL container type and a separate NOVEL content record - we just show the container record as its own content. Likewise, when a Chapterbook's contents can only be described by the overall name of the Chapterbook, we could let that stand on its own in the same way, rather than create an identical SHORTFICTION title. What I don't want to see is people entering actual Chapters just so that we can have some named contents. It's a balancing act - is there enough of a benefit to warrant doubling the entry effort? In some cases, I'd say no. BLongley 18:34, 13 July 2009 (UTC)

In such a case (novel without content record) an edit gets warnings that things are in an unstable state (or at least some edits do), and I don't think any moderator would knowingly approve an edit that created such a situation -- I'm sure that I wouldn't. -DES ^Talk 19:19, 13 July 2009 (UTC)

I don't think you understand what the software is doing, or what the database holds. I'm not talking about Novel Pubs without content records. I'm talking about a Novel pub with a Novel title in it, that does not need to be hidden as it defines the contents of the publication without any need for another Novel (Content) record to go with the Novel (Container) entry. For Collections and Anthologies and Nonfiction, we (helpfully?) hide the Container title as the contents are defined by Shortfiction, Essays, Interiorart, etc, instead. At the moment, Chapterbook Container titles are hidden in pub edits so people can get their heads around the fact that the Chapterbook is NOT always the same as the content. But we can reveal the Chapterbook entry for additional information if that is simpler - for Novels, we use it to put a page number on but the fact that we can create a shortfiction length for a Novel is (currently) useless. (or should we develop that so we can cope with Novels that were Novels before the various Award Committees decided otherwise?) For Chapterbooks we could use it to put both a page number and a fiction length on, and that might be useful. (Not to me, but it's an option.) BLongley 20:46, 13 July 2009 (UTC)

I am suggesting that a chapterbook with no fiction title record associated with it, is analogous to a novel without a content record. But the closer analogy is perhaps to an anthology with no content records, because in many ways a chapterbook is being implemented more like an anthology than a novel. And while I haven't torn into the actual code yet, i have worked on a number of database projects, and I think I understand exactly what is being stored. The real question is of the model being used -- of what real world entity each type of database record represents. It seems to me that the fiction title records, such as NOVELs and SHORTFICTION represent texts, assemblages of words. Publication records represent physical (or in the case of ebooks, electronic) instances of those sets of words (possibly along with art), and container titles, like Anthologies, collections, omnibuses, and chapterbooks represent a grouping of similar publications that it is useful to think of as instances of the same thing. The NOVEL title in this model, fills two roles at once, it is both a fiction title and a container record. In other types there are normally three things: an anthology has a title record, one or more publication records, and one or more fiction (content) title records (and possibly essay, poem, and other text-type records). So does each of the other container types. i am saying that the chapterbook (or whatever we eventually call it) should follow this pattern, in part because in many cases the fiction will be also published in a non-chapterbook format, and it always could be. Granted we don't HAVE to use that model, but I think it makes the most sense. -DES ^Talk 21:51, 13 July 2009 (UTC)

Similarly I would pretty much automatically create a shortfiction title for any chapterbook publication i found without one. Whatever we call it, there is text -- fiction -- printed in a chapterbook. Since it was separately published, I think we need to record it somehow. -DES ^Talk 19:19, 13 July 2009 (UTC)

We are recording it - as a Chapterbook. Sometimes it might be useful to record separate contents, sometimes it won't be. This is why I mentioned the "excerpt" problem. If someone really knows a Chapterbook is "Chapters 1-3 of Novel X", fine, add that. BLongley 20:46, 13 July 2009 (UTC)

But it is at least possible that the same collection of words will be reprinted in another form, in an anthology, for example. The shortfiction contents entry is the thing that will be in common for any such re-use. -DES ^Talk 21:51, 13 July 2009 (UTC)

And when such happens, I agree, I just don't see a major need for such on every kind of chapterbook until that happens. Things that may be accumulated into something bigger probably need an overall Shortfiction title, things that are definitely subsets of something already published probably don't, IMO. I can't see anyone reassembling the "The Lion, the Witch and the Wardrobe" chapterbooks into anything other than "The Lion, the Witch and the Wardrobe". But I see you're working on some of the more difficult examples already, all this can wait till we can show some examples and see how ugly things are getting. The name is looking like the least of our problems! (And I can already see why Al ducked the issue.) BLongley 20:48, 15 July 2009 (UTC)

I agree that it is unliklely that all or most of the parts of this will ever be reassembled into anything but "The Lion, the Witch and the Wardrobe". However I could see a new anthology sort of like Lin Carter's Dragons, Elves and Heroes which reprinted excerpts from classic works of fantasy, using the text of one of the chapterbooks as a handy excerpt of TLtW&tW. I could also see a hypothetical "C. S. Lewis Reader" doing the same thing. Mostly, if such reuse happens, i would want the new pub to be recorded and merged in the normal way, not needing the editor to figure out "Oh yeah, no fiction title was ever recorded for that chapbook, now I need to add one." Indeed worse, if a standard merge attempt found nothing to merge, an editor assuming incorrectly that the excerpt had not been previously published. I want to make things as standardized as possible, not have some chapterbooks contain fiction titles and some not, but have all contain such, so they cam be dealt with in standardized ways. Still we can wait until there are some additional examples at hand, there I agree. -DES ^Talk 21:11, 15 July 2009 (UTC)

Yes, it can definitely wait. I've still got to read and compare some of the bloody things. :-( Fortunately, I resisted buying a set of the Green Mile Chapterbooks last Sunday - "First editions" they may be, but I'm not paying £2.95 per book when I can get the entire set in one volume for less. BLongley 21:36, 15 July 2009 (UTC)

Just as novels split for republication are still entered as novels, not as segments of novels (nor as serials, although a case could be made for that), longer works split for publication as chpterbooks should IMO be recorded as fiction of some kind, and shortfiction with proper notes about it being an excerpt of the longer work seems like a good idea to me. When a single longer work is split into several chapterbooks, that together contain the entire longer work, I could see an argument for using a SERIAL type insterad of shortfiction, looking at the enclosing chapterbooks as being comparable to the issues of a magazine in which more traditional serialization takes place. If we wanted to create a new EXCERPT type, that might make sense too. But IMO there has to be some sort of content record. -DES ^Talk 19:19, 13 July 2009 (UTC)

We can let the container type be the content type too. We do it for novels. I'd hoped that somebody would have tackled The Green Mile by now though. :-( BLongley 20:46, 13 July 2009 (UTC)

I've been working on it -- I've finished part 3, Coffey's Hands. -DES ^Talk 21:51, 13 July 2009 (UTC)

Which is why novel isn't really a container type, quite. -DES ^Talk 21:51, 13 July 2009 (UTC)

(unindent) I have found a bug in the chapterbook support. See Bug #2820836 Making chapterbook a variant creates an anthology. If a chapterbook has been published under a pseudonym and you create a parent VT under the canonical name, the parent is created as an ANTHOLOGY and must be manually fixed. It now can be, but unless you look at the new parent you won't notice that it needs to be fixed. -DES ^Talk 16:05, 13 July 2009 (UTC)

Does anyone speak French?

I’d like to ask the people behind www.collectorshowcase.fr for image linking permission as they have a fantastic specfict cover collection and don’t trust Babelfish to do it politely. --Marc Kupper|talk 08:00, 7 July 2009 (UTC)

I took french in high school and college, but it has been a long time. i could probably read french, with the help of a dictionary at least, better than bablefish but I'm not sure I can write it. However, my sister knows french fairly well -- I'll ask her. -DES ^Talk 13:02, 7 July 2009 (UTC)

Thank you. I found someone locally who knows some French and so I'll run it by her. I'm giving her both the English and Babelfished versions of the letter and she can review and mark up the Babelfish results. We can compare notes with your sister. --Marc Kupper|talk 04:18, 8 July 2009 (UTC)

Or we could try English first :) Ahasuerus 04:39, 8 July 2009 (UTC)

Agreed but the site did not offer a hint of English other than the main site name. Bad French is more likely to get a positive response than asking in English. I've posted a machine+human translated version to ISFDB:Image linking permissions#Sample request for permission - French. DES, if you can run the English and then translated copy by your sister then that would be great. Thank you. --Marc Kupper|talk 00:46, 9 July 2009 (UTC)

I will do so. Perhaps this weekend. I have some reservations about your note on omitting the "technical" bits, will post those on the talk page. The translation looks at least reasonable from my limited remaining skills. -DES ^Talk 00:48, 9 July 2009 (UTC)

See ISFDB talk:Image linking permissions#Ommitting technical bits -DES ^Talk 00:59, 9 July 2009 (UTC)

Review display: Bug?

When a review is written by two or more reviewers there seems to be an oddity in the way it displays on the reviewers' biblio pages. For example see Mark Shainblum. In the reviews section we see:

Reviews
 ● Guns of the South (1995) by John Dupuis  and Harry Turtledove
 ● Worldwar: In the Balance (1995) by John Dupuis and Harry Turtledove

This turns out to mean that Shainblum & Dupuis jointly reviewed the two Turtledove novels. In this case, since Turtledove and his works are well known, few if any users will be confused into thinking that Dupuis and Turtledove were joint authors. But suppose that both the people involved and the work were more obscure. A user could easily be confused. Perhaps if the display looked more like:

Reviews
 ● Guns of the South (1995) by Harry Turtledove [reviewed with John Dupuis] 
 ● Worldwar: In the Balance (1995) by Harry Turtledove [reviewed with John Dupuis] 

Or some other format that does not imply that the co-reviewer was actually a co-author. Do people agree that this is a bug? Or perhaps just a desirable enhancement? -DES ^Talk 21:46, 7 July 2009 (UTC)

I think this issue was reported as a bug before, but I don't see a bug report on file. Must have been a casual encounter with applied entomology :) Ahasuerus 21:56, 7 July 2009 (UTC)

I see. Well then, see Bug #2818246 (Fix display of reviews with multiple reviewers) which i just logged. Swat! -DES ^Talk 22:02, 7 July 2009 (UTC)

Patch r2009-08

Patch r2009-08 has been installed on the live server. The following changes have been made:

• Bug 2797544. In Advanced Author and Publication searches, fixed overlapping pages past page 1.
• Bug 2799063. Added Advanced Publication Searches by Publisher, Price and Page Count. Disabled searches by Cover artists for performance reasons. Improved performance of Author and Publication searches.
• Feature 2816520. Added Missing "Edit record" and "View record" links after approving Title or Author edits.
• Bug 2814984. Fixed the display of Title records when an ISBN-10 is stored with dashes.

Please report any issue here. Thanks! Ahasuerus 23:56, 7 July 2009 (UTC)

Will the "Sort by" function be fixed in "Publication searches" any time soon or is this a more complicated problem?Kraang 01:39, 8 July 2009 (UTC)

As far as I can tell, sorting is broken in all Advanced searches that are supposed to support it. I have created a new bug, 2818319, but it's not clear how long it will take to fix the problem. Ahasuerus 02:39, 8 July 2009 (UTC)

Magazine:The New York Review of Science Fiction

Two questions about Magazine:The New York Review of Science Fiction. First, do we want to move it to the "Fanzines" page? Second, do we have volunteers who would be willing to enter the last 5 years worth of issues (perhaps splitting the load between 2+ people)? There is an Excel spreadsheet with all of the issues indexed, but NYRSF's data entry conventions are not the same as ours, e.g. a review of a co-authored book is entered as two separate reviews, so it would take longer to write a script to upload the data to ISFDB via our Web API than it would take to enter the data manually. Ahasuerus 02:49, 8 July 2009 (UTC)

Is the spreadsheet on line? I don't have the time for manual entry but wanted to see how painful it would be to script it. --Marc Kupper|talk 04:21, 8 July 2009 (UTC)

It's downloadable from here. Was quite useful when I was fixing the missing editor records and fixing the more obvious errors. BLongley 18:38, 8 July 2009 (UTC)

That one is current as of issue #248 while the copy that I have also includes #249. Otherwise they are very similar except that the online version hides columns C-F for some reason. Ahasuerus 20:33, 8 July 2009 (UTC)

I'm not sure where you got that from, I just went to the website and looked at the "NYRSF Index" column in the middle. Is one stable and official and the other not? BLongley 21:35, 8 July 2009 (UTC)

I have their top secret internal version, which cost the lives of two of our best agents to procure! Or at least it would have if we had any agents... Ahasuerus 22:34, 8 July 2009 (UTC)

(Checks "Unavailable moderators" section of Moderator availability, shuts up.) BLongley 22:57, 8 July 2009 (UTC)

We can't always name those sacrificed to the cause but perhaps we can have rocket ships and unicorns on a memorial page much like the CIA's memorial wall that has nameless stars? --Marc Kupper|talk 01:03, 9 July 2009 (UTC)

It's about 1Mb, so I sent it to you via e-mail. It's doable, but there are quite a few Essay/Review/Interview permutations and some things would require human intervention anyway. Ahasuerus 04:38, 8 July 2009 (UTC)

Thank you Ahasuerus, I have the sheet. The bad news is there are many data entry conventions that'll need some thinking and as it seems like a human entered spreadsheet it's likely they were not consistent with their conventions. The good news is that we already have some 15 years of issues already in ISFDB meaning the scripting code can first be used to validate both the code and those entries. We'd then unleash the code on the five years of issues that have not been entered into ISFDB. --Marc Kupper|talk 01:03, 9 July 2009 (UTC)

Showing our incompetence again

I know a lot of us just go directly to the next bit of ISFDB they're working on, and don't even notice the home-page. I do try and pay attention to it, but can't promise to do it every day, and certainly can't promise to do it exactly as each day starts. But I do think we can improve on entries like:

Authors Born On This Day:
   * Anne Radcliffe (1764-1823)
   * Ann Radcliffe (1764-1823) 

One is surely enough? Just adjust the author data for the variant and it shouldn't get picked up. BLongley 21:44, 9 July 2009 (UTC)

Deleting the pseudonym record's biographical data sounds reasonable and we could easily write a script looking for pseudonyms with populated bio fields. In addition, we could change the Home Page code not to display any Author records that are marked as "Pseudonyms". Ahasuerus 02:19, 10 July 2009 (UTC)

And I don't think we need to show two Destroyer of Worlds and two Oceanic and two The Republic of Thieves - but that will need a code-change I think. Are people agreed that one edition of a title is enough on our home? If so, which one, or should we try and mention them all in one display entry? BLongley 21:44, 9 July 2009 (UTC)

That could be trickier and we'll need to review the underlying logic to see what it is doing. Ahasuerus 02:19, 10 July 2009 (UTC)

They are listed twice because there are two editions coming out. That seems reasonable to me. Dana Carson 01:23, 11 July 2009 (UTC)

Given the limited real estate on the main page, one could argue that we would be better off displaying only one Pub per Title. There is a long list of books clamoring to get on the front page :) Ahasuerus 01:33, 11 July 2009 (UTC)

After a quick review, I've resolved some problems: The Republic of Thieves is not coming out any time soon, we just don't check forthcoming entries much for changes in potential publication dates. "One pub per title" sounds good to me. To get a fair balance, we might also want to consider limits on number of publications by an author ("Charlaine Harris" is over-represented, IMO, just because there's a load of reprints coming out this month) or by publisher. I'm tempted to prioritise new titles over reprints of titles. Maybe new authors over existing ones. Or just start demanding proper bribery to make us sort the page the way the publishers want. (I can't see any way to make this a Rules and Standards discussion, it's a completely different sort of issue.) BLongley 00:23, 12 July 2009 (UTC)

Prioritizing new titles over reprints sounds reasonable -- how many users do we have who are dying to learn that the 174th printing of The Hobbit is about to be released? -- although there are occasional reprints that are eagerly awaited. As far as being properly bribed by publishers goes, well, we could always ask them to send us complete lists of their forthcoming SF! Ahasuerus 03:40, 12 July 2009 (UTC)

If a book has been out of print a while, i am often interested in a forthcommign reprint. Less so a new printing or even edition of a widely available book, but I can't see how an algorithm could usefully make that distinction. -DES ^Talk 15:29, 12 July 2009 (UTC)

Well, pub date matching title date should indicate a new title. A "long out of print" title could be spotted by checking for pub date being X years after the latest pub date for that title - although 0000-00-00 pubs will skew those. Are people interested in changing this? (Publishers - contact me directly and tell me how many books I get for free if I work on this.... ;-) ) BLongley 19:42, 13 July 2009 (UTC)

I think it might be nice, but it isn't a high priority for me. I do think that limiting the front page to displaying only a single publication of a given title, even if, say, an HC and a TP come out together, seems like a good idea. A negative modifier for the 2nd through Nth titles by the same author might make sense too, but i wouldn;t get too excited about tryign to fine tune the list overmuch, myself. -DES ^Talk 22:00, 13 July 2009 (UTC)

"lists of"? Just let them send me the actual books and I'll make sure they're here! BLongley 10:21, 12 July 2009 (UTC)

On the plus side - I see less "unk" bindings there nowadays. And we might even have Collection and Anthology contents sorted by publication date at times. But this is often the first page people see, and it would be nice to have just those few pubs sorted before we make them so prominent. BLongley 21:44, 9 July 2009 (UTC)

Speaking only for myself, I probably could count on two hands the number of times I've even seen the home page. I found ISFDB through a link on wikipedia, to a specific page. From that I started entering data. (I'm not sure how I found that I had a talk page.) Not only do I not notice the home page, I literally don't even go to it. I've got some things bookmarked that get me where I want to be. Just FWIW. -- Dave (davecat) 02:34, 10 July 2009 (UTC)

14,600 visitors every month. Interesting list of affinity sites. --swfritter 17:00, 10 July 2009 (UTC)

15% regulars, 85% passers-by. Apparently we addicts don't quite register yet. BLongley 20:41, 10 July 2009 (UTC)

Header templates

I's like to call people's attention to Category:Header Templates, and particularly to {{AuthorHeader}} (or the alternate version, {{BibHeader}}) and {{BioHeader}}. I ask that when creating a new Author: or Bio: page, or editing an existing one, you place the appropriate header template at the top of the page. -DES ^Talk 15:26, 12 July 2009 (UTC)

Unfortunately, I do it so infrequently that I always seem to forget to include the template :( Ahasuerus 15:30, 12 July 2009 (UTC)

DES added redirects so that you don't need to remember the exact spelling of how to invoke the correct header. A mnemonic device is that adding "Header" to the namespace name will get you to the template. For example if you are at Author:Avi then the namespace is "Author" and the header would be {{AuthorHeader}} though if you accidentally use {{Author Header}} it will still work. If you find yourself entering a name that gets a red link, {{Bibliographic Comments}} for example, then we can set up redirects or aliases for those to point at AuthorHeader.

There is one minor exception to the namespace mnemonic device which is that Bibliographic Comments for publications use {{PubHeader}} rather than the {{PublicationHeader}} you would arrive at if you used the full namespace name.

I like using the headers as all I need to type is {{AuthorHeader}} or {{PubHeader}}and I'll get a link back to the correct ISFDB bibliography page. --Marc Kupper|talk 09:31, 13 July 2009 (UTC)

We have now got {{SeriesHeader}} working also. For publication series, there is now {{PubSeriesHeader}}, but that is a bit different, as many publication series don't have ISFDB series entries in the db, so if there is one, you must supply the id parameter.-DES ^Talk 14:32, 13 July 2009 (UTC)

Help:Header Templates now describes the available header templates in what I hope is a well-organized way. -DES ^Talk 19:30, 15 July 2009 (UTC)

Quotes issues

Double quotes in Author names (but not in Title or Publication titles) have been a major headache for years. For example, to quote Bug 1743286:

Quotes cause Author name truncation when editing Reviews. If a Publication contains a Review record and the author of the reviewed book has quotes embedded in his or her name, e.g. E. E. "Doc" Smith (http://www.isfdb.org/cgi-bin/pl.cgi?152751), then pulling the Pub record up in Edit Pub results in the loss of all characters in the Author's name to the right of the first quote. Ahasuerus 23:40, 27 Feb 2007 (CST)

Although it's possible to fix the bugs associated with double quotes in Author names, it occurs to me that there is another, larger issue here. We currently allow our users to enter both single and double quotes in Author and Titles names and yet we also say in Help:Screen:EditPub:

Quotes can be entered either as single (') or double (") quotes. They are considered interchangeable typographical artifacts and no variant titles should be created for versions of the same story that use different types of quotes.

This doesn't give our users any guidance re: the type of quotes they should be using when editing or searching the data. How can a user tell whether he should be searching for "And He Built a Crooked House" or 'And He Built a Crooked House'?

Here are a few things that we could possibly do to address these problems:

1. Change all Author names with double quotes to use single quotes instead. There are about a dozen of them, so it should be fairly easy. (Naturally, we will need to check whether the single quote version of each name already exists.)

2. Prevent new Author names with single double quotes from being created by either giving the editor a pop-up error message along the lines of "Double quotes in Author names are not allowed. Please use single quotes." or automatically converting double quotes to single quotes when creating submissions and notifying the user on the post-submission page.

3. Enhance the search logic so that a search on an Author name like E. E. "Doc" Smith will be automatically changed to a search on E. E. 'Doc' Smith.

I think this should address all (?) known Author name issues. If it works to our satisfaction, we could tackle Titles by applying the same steps except that the first step would need to be automated since there are so many of them.

Does this sound like a direction that we want to take? Ahasuerus 23:29, 12 July 2009 (UTC)

For authors the above sounds fine. (Somehow I thought it was single quotes tast caused the problem.) (and in step 2 above don't you mean "Prevent new Author names with double quotes from being created"?)

Oops, sorry about that! Ahasuerus 00:10, 13 July 2009 (UTC)

For titles the single vs double quote issue may actually matter in some cases, and we also have the issue of straight vs curved single quotes. (I am thinking of the possibility of an embedded quote in a title, using both single and double quotes to show this.) I do think that any search for any form of quote should automatically match any other form. I am inclined to think that we should convert curved to straight quotes on save. Whether to preserve single vs double quotes in titles I'm not sure, but if they don't cause problems, why not. Then we could clarify the help. -DES ^Talk 00:01, 13 July 2009 (UTC)

I'm certainly in favour of standardising double-quotes to single for author names. For titles, I think keeping single and double quotes might be needed - but definitely do not allow "curved" quotes or the 66/99 style of double quotes. ASCII codes 34 and 39 (decimal) should be good enough for us. BLongley 19:33, 13 July 2009 (UTC)

One other quote issue while we're at it - I got caught out at times with bindings like 7¼" x 9¾". I didn't enter such, just found that they silently broke when fixing other things in the publication. BLongley 19:33, 13 July 2009 (UTC)

True, but I'd be happy with a standard that such are entered as "7¼ in x 9¾ in" or even as "7¼ x 9¾ in". I quite agree on curved single and double quotes -- stick to basic ASCII forms, and convert on storage, if possible. -DES ^Talk 21:55, 13 July 2009 (UTC)

I'd be happier still if we banned "¼" and "¾" as well - they're not ASCII characters either. But that's a separate issue, which should be covered under the "standardised bindings" discussions that we never finish. :-( BLongley 19:54, 15 July 2009 (UTC)

I agree "7 1/4 in." works well enough. -DES ^Talk 19:57, 15 July 2009 (UTC)

Revisiting Variant Titles

Now that "also appeared as" and "only appeared as" have been live for a couple of weeks and we have gotten used to them, it occurs to me that the words "Variant Title:" may no longer be needed. Should we remove them from the Summary Bibliography page and rely on "also/only appeared as" and indentation to convey the same meaning? Ahasuerus 00:08, 13 July 2009 (UTC)

I've thought about this for a while.... and don't have an objection, but we may want to beef up (create?) a 'How to Use the ISFDB' section, since now the obvious 'training' for what is a variant title will have gone away. Kevin 22:26, 13 July 2009 (UTC)

That is actually a reason to keep the words "Variant Title:", IMO. They may be redundant, but they may help make what is going on clearer, and I don't see that we gain much by omitting them. If we do retain them, we might want to change the wording to ""Variant Title or Author:" or else just "Variant:" because when all that varies is the author credit the term "variant title" is less than ideal. -DES ^Talk 22:34, 13 July 2009 (UTC)

Sure, I can see clarity being a concern. It's just a minor presentation issue, so we can always experiment with different options, e.g. Variant:, and see how it goes. Ahasuerus 23:55, 14 July 2009 (UTC)

"Variant Title or Pseudonymous Work" is a bit long winded although we use that in places, but abbreviation to "Variant" and some updated Help on what "Variant" can actually mean looks good to me. It'll be a starting point for discussions on "expanded", "revised", and all the other things we might want to use some sort of variant relationship for. BLongley 20:00, 15 July 2009 (UTC)

translated shortwork titles

I'd like to call attention to The Legend of Sigurd and Gúdrun and in particular my note "The titles of the two long poems (lays) in Old Norse are the only titles at the start of each poem. The translations of the first of the two alternate titles in each are given in the ToC, the translations for the second alternate title (after the "or") of each is given in the Introduction by Christopher Tolkien." Does this seem a reasonable way to handle this sort of situation? Should this rare case be mentioned in the help? Would the same sort of solution apply for book-lenght works with non-English titles, but whose contents are in English?

The Green Mile

I ahve been doing some work on Stephen King's The Green Mile. As some of you will know, The Green Mile was first published as a "serial novel", issued in the form of six segments, apparently all of 92 pages for the first edition. Thes have been recorded here as 'chapterbooks". The first complete publication was "A boxed set of the six individual books." and has been recoded in the ISFDB as an omnibus, as have several reprints. However, at least three publications, one verified (by a no longer active editor) have been recorded as novels. I would like to merge 641469 with 26690 (the omnibus title). But a merge of a novel with an omnibus is a bit rare, and this would affect a verified pub. Also, future pubs of the complete story may look more like novels than omnibuses. So I would like some views as to whether this is a wise move (an alternative would be to class the original publications as type SERIAL, but that has other concerns). Comments, anyone? -DES ^Talk 23:11, 14 July 2009 (UTC)

I agree that the one-volume edition should be a NOVEL instead of an omnibus, but we all know that novels are not really container pubs for SHORTFICTION and won't support the inclusion of the individual pieces. (We work around this when a novel contains an excerpt from a forthcoming novel, but that doesn't work very well.) We could do it like fix-ups where we put links to the constituent parts in the title record. That might work here, but then the title records for the individual parts won't show they were published as a novel. Any way you look at it, you wind up with square pegs in round holes. MHHutchins 00:19, 15 July 2009 (UTC)

Obviously i wasn't quite clear. i was suggesting merging the novel with the omnibus, and retaining the omnibus, so that the one-volume edition would not be a novel.

Technically, of course, shortfiction works can be included in novel publication -- this is done for a number of cases where novels are published with "bonus stories". it is a matter of convention not to call something with 6 shortfiction titles a novel. I agree that no solution is perfect here. -DES ^Talk 01:57, 15 July 2009 (UTC)

May I also offer for consideration Starfleet: Year One. (I finally tracked down all twelve titles, in all 24 pubs, yay, go me!) As the final book publication seems to have been revised I'm tempted not to make it the sum of its parts. And I don't want us going down to Chapter level unless absolutely necessary. How do people feel about having NOVEL variants of OMNIBUS titles for cases like this, rather than merging? BLongley 20:25, 15 July 2009 (UTC)

Also, note that Bag of Bones / The Green Mile / The Girl Who Loved Tom Gordon is an OMNIBUS already, and so would have problems containing a different OMNIBUS. BLongley 20:25, 15 July 2009 (UTC)

Variant works for me. If we ever implement "based on" or something like it, we can always reconsider. -DES ^Talk 20:35, 15 July 2009 (UTC)

Patch r2009-09 is live

Patch r2009-09 has been installed on the live server. It includes the following changes:

• Feature 2799065. Advanced Title searches by Author are now much faster. Advanced search by Reviewed Author has been added.
• Feature 2807731. Moderator approval screen now link to the submitting editor's Talk page as well as to his User page.

I was hoping to push other features out the door as well, but between illness and technical discussions re: the best way to implement some of these features, things were taking too long, so other changes will have to wait until the next patch. Ahasuerus 03:51, 15 July 2009 (UTC)

• When the page displayed is a series, the editing tools section of the navbar contains "Series Data". Wasn't this supposed to change to "Edit Series Data" along with the other navbar changes? -DES ^Talk 20:00, 15 July 2009 (UTC)

Not in this release, it seems, neither of those features covers navbar changes. But now Reviewed Author search is in, I hope to see a lot less "Orphan" authors with no titles. And now we've saved you a click each time you want to talk to a submitter, I expect you to use your new free time on such. ;-) BLongley 20:09, 15 July 2009 (UTC)

Patch r2009-10 live

Patch r2009-10 has been installed on the live server. This is a small "proof of concept" patch which lets developers and testers configure their locally installed Wiki the way they want. The only change from the user perspective is that when you edit a Series record, the system will now display the same "Your submission must be approved by a moderator before it enters the database" warning that it displays when you create a new Publication record. If there are no problems reported by tomorrow night, I will roll out similar changes to various other data submission forms. Ahasuerus 03:48, 16 July 2009 (UTC)

I've tried a few series edits tonight, they look fine. BLongley 20:59, 16 July 2009 (UTC)

Patch r2009-11 installed

Patch r2009-11 has been installed on the live server. The following changes were implemented:

• All but 1 pseudonymous review records which were missing Reviewee fields have been fixed. The last one is being investigated.
• Added links to the submitter's Talk page on the post-submission page for Pub Edit, Title Edit, Delete Pub, Delete Title, Remove Title from Pub, Make Variant (both submit buttons), Clone Pub, Edit Author, Link Review.
• After approving a change to a Series record or "Removal of a Title from a Pub", the approving moderator can now edit or view the changed Series/Pub record.

As always, please speak up if you see anything unusual. Ahasuerus 03:26, 17 July 2009 (UTC)

Can you let me know what the one oddity for "pseudonymous review records which were missing Reviewee fields" was? ("is"?) BLongley 22:51, 17 July 2009 (UTC)

There appears to be something funky with Bryan Cholfin's (aka "Bryan G. Cholfin") review of Jeanne Gomoll The Bakery Men Don't See. The canonical Review Title lists the reviewee as "unknown", which may well be a data entry error. Ahasuerus 23:41, 17 July 2009 (UTC)

User Preferences

As per recent discussions, I have created Feature Request 2823095, which currently reads:

We need a "User Options Preferences" Web page that would allow our users to choose what kind of data they want to see, e.g. which stores they want the navbar to link to for Publications. Other options will be added later via other Feature Requests.

Does this sound like a good start? Ahasuerus 13:53, 17 July 2009 (UTC)

Frankly, I can think of several user options which seem of more value and urgency than that one, but it might be a reasonable proof-of-concept starting point. I suggest the term "Preferences" rather than "Options", but this is a trivial matter. -DES ^Talk 15:01, 17 July 2009 (UTC)

Good point, FR changed. Ahasuerus 16:48, 17 July 2009 (UTC)

Other user options/preferences that seem plausible to me off-hand:

• Which bibliography (summary, alphabetical, chronological, etc) should display as the result of clicking on an author link? (See #Duplicate entries on Summary bibliographies above.
• Log-in cookie expiration time
• Suppress image display, for off-line use of local copies, or for people with low-bandwidth connections, or visual impairments.

Doubtless others could be devised in future. -DES ^Talk 15:01, 17 July 2009 (UTC)

Oh yes, it should let us do all kinds of neat things! For example, it should enable us to support user-defined lists of "preferred languages". Once that is in place, I expect that we will be in a position to make the following changes:

• Add a new field, "Language", to Title records and populate them properly. (Multilingual books may be a headache, but they are fairly rare in the field.)
• "Mass change" foreign language translations of English language Titles from Pubs to regular VTs
• Change the Summary display logic to show only the Titles that match the current user's preferences
• Start entering foreign language translations of Shortfiction Titles and foreign language collections/omnibuses/anthologies that have no analog in English

Not only should it make life much easier for everyone concerned, it will also be an incentive for our users to create an ISFDB account since by default we will continue showing only the Titles that we are currently showing, i.e. the "original publication" Title and English VTs of foreign language Titles. Ahasuerus 16:48, 17 July 2009 (UTC)

Sounds like a good idea. -DES ^Talk 17:29, 17 July 2009 (UTC)

FR 2823394 has been created -- so that we don't forget this discussion -- and put on hold since we can't implement it until User Preferences are available. Ahasuerus 23:51, 17 July 2009 (UTC)

Variant display oddity

After discussion above, I made the one-volume Novel The Green Mile a variant of the Omnibus. This has the odd result that in the series display the line "The Green Mile (1996) [O] by Stephen King [also as by Stephen King ]" appears. I sort of understand why, but if this case could be handled better it would be nice. -DES ^Talk 17:36, 17 July 2009 (UTC)

Log a bug for this (if you can assign it, go ahead and assign it to me). Looks like the display expects either the title string to vary or the authorship to vary and isn't expecting the variation to be solely due to the title type. So once the titles are found to be identical, it's going into display-the-varied-authorship mode. Instead, it should probably consider identical titles to be same title string AND same title type.... --MartyD 17:44, 17 July 2009 (UTC)

Logged: Bug #2823249 (Variant display wrong when neither author nor title varies) and assigned to you. -DES ^Talk 18:49, 17 July 2009 (UTC)

Thanks, and fixed. Coming soon to an ISFDB near you. --MartyD 00:32, 18 July 2009 (UTC)

First "979 Prefixed" ISBNs Assigned

Latest Locus has an article that links to this. 13-digit 978 prefixed ISBN's have corresponding 10-digit ISBN's but other prefixes apparently don't. So our system will not attempt to convert a non-978 13-digit ISBN to a corresponding 10-digit ISBN?--swfritter 17:48, 17 July 2009 (UTC)

I've created FR #2823239 (Support for 979- ISBN-13s) on source forge. -DES ^Talk 18:14, 17 July 2009 (UTC)

Serials and Lexical Match

I have been thinking about Swfritter's comment re: Serials and how we could get rid of the infamous "lexical match logic" by making Serials into VTs of the parent Novel/Shortfiction Title. The more I think about it, the more doable it appears to be. We would need to have an automated conversion, of course, and tweak the Summary Bibliography display logic, but otherwise I can't think of any structural of functional hurdles. At one point I thought that pseudonymously published Serials may give us trouble, but as long as we link them directly to the canonical Novel/Shortfiction Title, I think we should be OK. Am I overlooking anything? Ahasuerus 00:08, 13 July 2009 (UTC)

Would the display change significantly from the existing display? -DES ^Talk 00:14, 13 July 2009 (UTC)

I wouldn't expect any major changes, we'll just need to decide whether we want to keep the line which currently reads Magazine/Anthology Appearances: or rely on the new "also/only appeared as:" text. The fact that serializations always say "(Part X of Y)" or "Complete Novel" is generally sufficient to identify Serials, but perhaps keeping the current line will make it more explicit for new/occasional users. As long as it's a display issue, we can always change the behavior back and forth. (Oh, and we may want to get rid of the word "Anthology" in that line since we generally don't use Serials in Anthologies.) Ahasuerus 03:04, 13 July 2009 (UTC)

Would serials continue to display both with their parent titles and in their own section? -DES ^Talk 00:14, 13 July 2009 (UTC)

At this time there are three Summary Bibliography scenarios as far as Serials are concerned:

1. If there is a (lexically) matching Novel Title, then the matching Serial records appear under that Novel Title only and not in the Serial section.
2. If there is a matching Shortfiction Title, then the matching Serial records are displayed twice, once under that Shortfiction Title and once in the Serial section.
3. If there is no lexically matching Title, then the "orphan" Serial records are displayed in the Serial section. Note that these "orphan" records may be actually related to an existing Novel or Shortfiction Title, but there is no way to link the two if the book appearance used a different title. Well, except for a few experimental attempts to link them, that is. (See, e.g., Starship Troopers vs. Starship Soldier on Heinlein's Summary page.)

If we implement the proposed change, then scenarios 1 and 2 will behave like scenario 1 currently behaves. Scenario 3 will behave the same way as it does now except that many Serials which currently appear there will be linked to their parent Novel/Shortfiction Titles and "move up in the world" to scenario 1/2. The remaining unreprinted Serials will still appear in a separate section, which I think is our preferred behavior. We could conceivably display unreprinted Serials without a parent Novel/Shortfiction Title in the Novel section, but I think that would just mess up our chronological order and generally confuse things. Ahasuerus 03:04, 13 July 2009 (UTC)

Suppose a co-author is credited for the serial and not for the unserialized novel, would the serial but not the novel appear on the co-author's page? or what? -DES ^Talk 00:14, 13 July 2009 (UTC)

Oh yes, there are quite a few permutations with pseudonyms and variant titles, which is what made me hesitate for a week or two. However, as long as we enter Serials the way they appear in their respective magazines/newspapers and as long as we link them to the canonical Title of their parent Novel/Shortfiction Title, I think we should be OK.

To use your example, if the Serial Title(s) appeared "as by X and Y" and the Novel Title appeared "as by X" alone, then the canonical title of the Novel will presumably credit both X and Y and there will be a VT for the Serial appearance "as by X and Y" and a VT for the Novel appearance "as by X". Granted, some cases can get convoluted, e.g. the first Skylark novel was serialized as by Doc Smith and Lee Hawkins Garby and that's what the first book editions (1946-1950) said on the title page. Subsequent editions credit only Doc Smith since Garby's contribution was dropped when Doc rewrote the novel in 1958, so we would link the Serial records to the canonical 1946 Novel Title by Smith and Garby. I suppose you could also have a case where Author Y's contribution was expunged between the time of the Serial appearance and the time of the first Novel appearance, but in that case one could argue that we wouldn't want to make the Novel version appear on Author Y's Summary page anyway. Overall I think that these cases will be sufficiently rare to make them "doable" on a case by case basis. Ahasuerus 03:04, 13 July 2009 (UTC)

As a matter of pure design a separate custom serial link would probably be better, IMO. Would that add significant code? I suppose it would, at this point. -DES ^Talk 00:14, 13 July 2009 (UTC)

Yes, that was one of my concerns as well... Ahasuerus 03:04, 13 July 2009 (UTC)

There are already some serials that are VT linked (as per Help) because the titles for the serials differ from the book.--swfritter 13:42, 14 July 2009 (UTC)

Yup, there are 346 (out of 3470) SERIALs which are currently set up as VTs and we will probably want to review them before we run the proposed database update. Other than that, I don't see any other objections, so I will run this idea by Al to see what he thinks. I believe he had some ideas in this area before his availability dropped to near 0. Ahasuerus 23:52, 14 July 2009 (UTC)

The proposed approach has been run by Al and he agreed with it. I'll create a new Feature Request over the weekend and we can then discuss various implementation details. Ahasuerus 13:49, 17 July 2009 (UTC)

(unindent) FR 2823387 has been created. Here is what is currently says:

As per recent Wiki discussions, we want to get rid of the "lexical match" logic for Serials and set up Variant Title relationships between Serial records and their parent Novel/Shortfiction records. The following changes will be needed:

1. Change the Summary Bibliography and Title page behavior so that Serial VTs would appear under "Magazine/Anthology Appearances:" rather than under "Variant Title:". (See the way Heinlein's Starship Troopers/Starship Soldier currently appears.)
2. Eliminate the lexical match logic on the Summary Bibliography page and on the Title page.
3. Identify and manually review/adjust the 300+ Serial records that are currently set up as VTs. Delete all fake Novel/Shortfiction Titles that have been set up to support the partial match logic.
4. Create a script that will find all Serial records that are currently NOT set up as VTs. For each one, check if there is a matching Novel/Shortfiction Title with the same Author(s). If there are 2+ matches, identify them as exceptions and generate a list which will need to be manually reviewed. If there is exactly one match, then automatically create a VT relationship between the Serial record(s) and the matching Novel/Shortfiction record.

Are there any other changes that will be needed? Ahasuerus 23:34, 17 July 2009 (UTC)

No further comments, so copying to the Development page. Ahasuerus 01:46, 21 July 2009 (UTC)

Patch r2009-12 is live

Patch r2009-12 has been installed on the live server. The following changes were implemented:

• Feature 2805588 - Added a "My Messages" link to the navbar. The text changes to "My Messages (new)" whenever there are new messages on the user's Talk page. Clicking the link takes the user to his/her Talk page.
• Bug 2804769 - Fixed a problem which resulted in ISBN searches not always producing complete results.
• Feature 2822160 - The post-approval page now allows the approving moderator to edit or view Titles after approving a Make Variant or Merge Titles submission.
• Bug 2820836 - Fixed a bug which made it impossible to create proper Variant Titles of CHAPTERBOOKS. CHAPTERBOOK VTs should now be fully supported and the new VTs should be of type CHAPTERBOOK.
• Bug 2823249 - Fixed a bug which resulted in Variant Titles which are the same as their parent titles except for the "Title Type" incorrectly appearing as author variations.

Please report any issues or problems here. Ahasuerus 22:18, 19 July 2009 (UTC)

P.S. There may be a problem with the background color of "My Messages (New)", which I am currently looking into. Ahasuerus 22:18, 19 July 2009 (UTC)

Desirable Feature(s)?

After finding this page I created a couple of notable Steve Gallagher pubs that never actually got published properly (well, one did after revision, the other is apparently a limited edition of one). Then I thought I'd add the pseudonym "Lisa Todd", just in case another Lisa Todd comes along, even though we wouldn't want the "Kids from Fame" novels. (Unless he's reached the "certain threshold"?) But we don't have "Add Pseudonym to This Author", just "Make This Author a Pseudonym". And even if we did, there's no Notes available on the Pseudonym to show why it's a pseudonym with no titles. I could get the pseudonym recorded the long way by adding one of the undesired pubs, creating the pseudonym, deleting the pub, and deleting the title, but I don't like that much work and it wouldn't end up the way I want anyway. So I suggest we might want these features:

• Notes on Author records so we can record the reason for a pseudonym credit
• Ability to "Add Pseudonym to This Author" (with mandatory note for above reason?)
• And possibly remove the option to "Make This Author a Pseudonym" from pages where it would be a Pseudonym of a Pseudonym?

Please discuss - there's no hurry on this, I think it's a rare case. Unless anyone knows differently? BLongley 20:29, 20 July 2009 (UTC)

Author notes would not be a bad idea, but if the requested featue to make it more obvious when the author bibliographic comments wiki-link has non-empty content is implemented, then putting such on wiki-pages seems to me as if it would handle things reasonably well -- there will always be cases where we want more recorded about an author than would comfortably fit in a db note (such as a biblio in the process of being transferred to or checked against the db, for example see Author:F. Paul Wilson) so we need this capacity in any case, i think. -DES ^Talk 20:56, 20 July 2009 (UTC)

As always, I see such information being in the database itself, rather than the Wiki, more useful. BLongley 21:27, 20 July 2009 (UTC)

When possible, yes, But there will always be cases, IMO where the volume of supporting data requires the wiki, or something like it. -DES ^Talk 00:04, 22 July 2009 (UTC)

I don't see the value of adding a pseudonym with no publications. In this case, the only titles written by Steve Gallagher as "Lisa Todd" as not SF, and he pretty much says that he never intends to use that name again, so why confuse things if an author of actual SF published as by "Lisa Todd" should someday appear? -DES ^Talk 20:56, 20 July 2009 (UTC)

Because if a "real" Spec-Fic Lisa Todd appears we wouldn't want to credit Stephen Gallagher's pubs to that author. We can reserve the titles, by entering them: or we run the risk of people misattributing them. Or we can leave it in Author notes and hopefully stop people assuming things that aren't true. We've already had people "helpfully" make all titles by author A (known to be a pseudonym of Author B) variant titles, where really all we know is that author B wrote some books as Author A. BLongley 21:27, 20 July 2009 (UTC)

For convenience, I could see starting the Pseudonym link from the parent author where both authors are already on file, but it doesn't seem like a big deal to me. -DES ^Talk 20:56, 20 July 2009 (UTC)

This would be a case of creating a pseudonym we do not want titles for, to "reserve" the name against future incorrect additions. It does not concern two existing authors. BLongley 21:27, 20 July 2009 (UTC)

But that is exactly what I think we should not do, at least in this case. Stephen Gallagher wrote two non-SF works under the name "Lisa Todd". If "Lisa Todd" is listed in our records as a pseudonym, and a different author later uses that name to write SF, then one of two things will happen. a) An editor will simply enter them as they stand, and the then existing pseudonym relationship will automatically attribute them to Gallagher, exactly what we want to avoid. Or b) the entering editor will actual notice the pre-existing pseudonym , and will respect it, forcing the creation of "Lisa Todd (born 1992)" or some such. Disambiguated authors are a pain to work with, and should not be created without actual need, IMO. I think that a) is actually more likely, but neither is good. -DES ^Talk 00:43, 21 July 2009 (UTC)

(a) shouldn't occur - it's NOT going to automatically attribute them to Gallagher, each title will have to be looked at. And a big warning on an existing Lisa Todd author record should help - that's why I suggested Author notes as the first change. I don't think I'd want the rest without it. BLongley 20:58, 21 July 2009 (UTC)

I think (b) is actually the desired effect. The Author record for "Lisa Todd" should have notes directing people to the Stephen Gallagher pseudonym or the "real" Lisa Todd, or the other author using "Lisa Todd" as a pseudonym. BLongley 20:58, 21 July 2009 (UTC)

I agree that disambiguated authors are a pain, but where they're necessary, I think this will help. We can have a "David Alexander" with notes that points out we want to put titles under "David Alexander (1907-1973)" or "David Alexander (1950's)". Or a "Rebecca Brown" that points to "Rebecca Brown (Born 1948)" and "Rebecca Brown (Born 1956)". It's not a huge problem, but I think that when we keep getting Mel Odom credited for "Mel Odom (artist}"'s work, name-clashes are best resolved by disambiguating both and a disambiguating author record (only possible via author notes really) would help. BLongley 20:58, 21 July 2009 (UTC)

I agree that author notes would help all this. But my feeling is that if we were to "reserve" an author name because it was used as a pesud for non-SF, than we ought to pre-disambiguate it. We could create "Lisa Todd (pesud of Stephen Gallagher)" and allow the unadorned Lisa Todd to be free of disambiguation, and not a pesud, if it is ever created. In cases where we actually have records for two different creators (authors, artists, editors, etc) of the same name, disambiguating both may well be a good idea unless one is quite well known. -DES ^Talk 00:15, 22 July 2009 (UTC)

While in case (a) variants would not be auto-created, a work appearing on the page of Author "Joe Doaks" which says at the top "Used as an alternate name by James Folkes" in a sense implies an attribution to Folkes of everything on the page, and I think many users will take it as such. That will happen with pre-reserved author names, in the absence of pre-disambiguation and/or good big author notes, and sometimes even with such features, i suspect. -DES ^Talk 00:15, 22 July 2009 (UTC)

I can actually see cases where a Pseudonym of a Pseudonym relationship might be appropriate. Suppose that "J. Random Author" wrote SF both under his own name, and under "J. R. Author" and "John Writer". Then "J. Random Author" died or retired. One "Richard Scribler" started writing continuations of "J. Random Author"'s popular series, under the "J. Random Author" name. (Such as has been done for V. C. Andrews.) Eventually there are more books under the "J. Random Author" name actually written by Scribbler than by the real Author. To correctly represent this mess, "John Writer" must be a pesud of "J. Random Author" which in turn must be a pesud of "Richard Scribler". If I am right, we should not prevent the creation of Pseudonym of a Pseudonym chains, but we should probably warn both editor and moderator when an edit would have that effect, because far more often than not it will be a mistake. -DES ^Talk 20:56, 20 July 2009 (UTC)

I don't see V. C. Andrews as a good example. She never wrote as anyone else, according to us. Consider Robert A. Heinlein instead. He is apparently a pseudonym of Frederik Pohl and Judith Merril. I can't think of a good example of where a Pseudonym of a Pseudonym is actually working well. Better examples please? BLongley 21:27, 20 July 2009 (UTC)

I don't have a real-world example in mind, which is why I invented one. Had V. C. Andrews used a pesud in life, we would have a complete example. But it is obviously possible in future, even if it hasn't happened yet. -DES ^Talk 00:43, 21 July 2009 (UTC)

I was asking about where they actually work well currently, not about future problems. I think our current "pseudonym of a pseudonym" support is broken. Author notes would help, a bit. But I think that Pohl and Merril being credited as Heinlein is confusing - separating the real Heinlein from the Pohl/Merril Heinlein might be better. So I still lean towards "pseudonym of a pseudonym is wrong" - I'd need more examples before I can propose a better fix though. BLongley 20:58, 21 July 2009 (UTC)

The current implementation may be broken and need rework. But if so, we need some way to handle cases where A wrote as B, but the real B wrote as C, just as Pohl and Merril wrote as Heinlein, but RAH wrote as Anson McDonalad and Caleb Saunders. We need some way to represent such cases, albeit perhaps not the current way. -DES ^Talk 00:02, 22 July 2009 (UTC)

I'm still thinking about the underlying "pseudonym of a pseudonym" issue, but for now I just want to point out that the Pohl/Merril/Heinlein pseudonym situation as it exists right now is wrong. Although Heinlein was the only officially credited editor of Tomorrow, the Stars and although Pohl/Merril (as well as Truman Talley and Walter Bradbury) did much of the editorial work, Heinlein was involved in the process -- see the recently added Notes at the Title level -- so there is no need for a pseudonym association. We will get rid of these two Pseudonyms once the software allows us to do that, at which point we will also need to review all other "pseudonym of a pseudonym" situations. Most of them are bogus, so once we eliminate them, we should have a (hopefully) manageable number which may give some clues ats to how to handle the issue. Ahasuerus 00:26, 22 July 2009 (UTC)

More Series options?

OK, I know the biggies are series deletion, and ordering sub-series within parents, and putting things into multiple series, and publication series as well as title series - those make my head hurt. However, one simpler new feature would be just to add notes and/or links to websites. For instance, this series has a website here. I know we can put it into the Wiki, but that doesn't help people working from the database alone. Do people other than me want such? BLongley 21:48, 21 July 2009 (UTC)

I would like notes, and I've already recorded a feature request at Source Forge for Wikipedia links. -DES ^Talk 23:57, 21 July 2009 (UTC)

Agree re: adding a free text Note field to the Series page similar to what we have for Titles and Pubs. Some Series have painfully convoluted publication histories and it would be beneficial to have them explained on the Series page as opposed to in the Wiki. Ahasuerus 23:27, 22 July 2009 (UTC)

FR 2827430, "Add a free text Note field to Series records", has been created. Ahasuerus 19:35, 26 July 2009 (UTC)

Yup, that's FR 2800720 - Series records to have external URL fields. I was going to compile a list of Series-related FRs after we were done with Serials-related "lexical match" issues, but there is no harm in doing it now. Here is what we have in Sourceforge so far:

New fields:

• FR 2800713 - Allow sub-series ordering
• FR 2800720 - Series records to have external URL fields]
• FR 2824361 - Support wikipedia link for series (FR 2824495 is a duplicate)

I think all of these are non-controversial. It's easy to add these 3 extra fields to the Series table and to the Series data entry form, but sub-series ordering will require a bit more work. Still, eminently doable and desirable.

Additional data entry validation:

• FR 2807944 - Prevent series name blanking
• FR 2807744 - Warn when creating duplicate series
• FR 2800717 - Variant titles have their own series field

The first two seem like no-brainers, although we may want to consider preventing users from creating duplicate series altogether and displaying an error message explaining what the problem is instead. I suppose the third one could be done by moving the Series name/number from the affected Title to the new parent Title at "Make Variant" approval time (if the parent Title doesn't have Series information associated with it), but would it hide too much complexity from the submitting editor?

New functionality:

• FR 2818090 - Allow removal of Sub-series from parent Series
• FR 2809640 - Allow empty Series deletion

No objections that I know of.

Productivity improvements:

• FR 2800715 - Set series when entering new title
• FR 2807767 - Series merge

The first one has been occasionally requested and seems to be non-controversial. The second one could be somewhat dangerous in inexperienced hands, but is certainly worth considering.

Series-related changes to other screens:

• FR 2813393 - Display Series info for VTs in Pub Contents display section
• FR 2805039 - Change display of shortfiction in series

I think we are better off implementing the first one in conjunction with adding dates to Contents level VTs on the Publication page. The second one would affect the display behavior everywhere, so we will need to discuss it separately.

In addition, we have two minor Series-related bugs, 2043760 and 2812300, which are not related to the existing FRs.

Also, as Bill said, there are at least two additional issues, "Titles belonging to multiple series" and "Publication series", which haven't been documented in Sourceforge yet. "Titles belonging to multiple series" would be hard to implement since it doesn't fit the current design, but we could consider adding "Secondary Series Name/Number" fields.

"Publication Series" would be presumably implemented as a new table similar to the current Series table, but linked to the Publication table instead of to the Title table, so it would be a different can of worms. Some of the challenges that come to mind are:

• What do we do with multiple printings of the same book in the same series?
• Do we want "Publication Series" to have the same "nested series" structure as the regular Titles Series or does it not make sense for them?
• What happens if a Publication belongs to more than one Publication Series?

Ah, the fun we'll have! :-) Ahasuerus 00:14, 22 July 2009 (UTC)

A very nice summary there, thanks! Would you mind flying over and doing the same for my current employers? I'm working on five projects that aren't my responsibility, and not getting anything done on the list of defects, or the list of development requests, or following the Incidents or Problems recorded in yet more systems... this place may seem like chaos at times, but it's the only place I actually get any work done! BLongley 21:13, 22 July 2009 (UTC)

It's good to know that I could always try to find a job as a requirements analyst :) Ahasuerus 23:23, 22 July 2009 (UTC)

I agree with Bill, a very nice summery. And I would support implementing pretty much all the above as soon as the developers find it workable. A few specific comments:

Variant titles have their own series field

FR 2800717 - Variant titles have their own series field To fully implement this I think we would need to have any change of series on the parent auto-propagate to the variant title, and disallow changes of series on the variant. The real objection as I understand it is to code which makes it possible for a title and its variant to have different series membership at any time.DES ^Talk 21:29, 22 July 2009 (UTC)

As it stands, variants by author should not be entered into a series, we only want the canonical author in there. Variants by title should be represented in series display. There are series like this and that that mean we daren't do title merges. BLongley 22:30, 22 July 2009 (UTC)

So is it fair to say that the easiest way to address this issue would be to enhance the Make Variant logic so that it would "move" the Series information (Series ID and number) from the VT to the newly associated parent Title? Ahasuerus 19:53, 26 July 2009 (UTC)

I think that would indeed be a major help when, for instance, you discover one prolific author is a pseudonym of another already represented. BLongley 20:58, 26 July 2009 (UTC)

Series Merges

Series merge could be dangerous if used carelessly, but so can title merge -- one reason why some titles have big "DO NOT MERGE" notes, and author merge is far more dangerous. I think moderators can be trusted not to approve dubious series merge edits without checking.DES ^Talk 21:29, 22 July 2009 (UTC)

If they're given enough information. I notice that "Diff pubs" doesn't consider notes, that should be addressed - more Mod tools please! "Diff Series" might be useful. BLongley 22:30, 22 July 2009 (UTC)

Sounds reasonable, but we will need to figure out how to do Series merge. At the moment, Author merges (and trickier Title merges) are done via Advanced Search, which doesn't let you search Series records. I suppose once we add all of these new Series fields, we could add a "Series Search" section to the Advanced Search screen and allow Series merges from there. Ahasuerus 20:05, 26 July 2009 (UTC)

Change display of shortfiction in series

FR 2805039 - Change display of shortfiction in series

This may need separate discussion, but when it was discussed before, no one seemed to object to it, although there was no clear agreement on exactly what to change to. I would like to push ahead with this one. And since I see we are now using [ES] tags on essay titles in some displays, I think that FR 2811725 -- Legend for biblio display pages has become a bit more urgent.

A legend would be easy to implement, we just need to make sure that we put the link to it in a single consistent place so that our users don't have to hunt for it the way we currently hutn for the right link in the navbar. Ahasuerus 20:05, 26 July 2009 (UTC)

Works in multiple Series

Works in multiple series could be handled by making the Series name/Series No fields multiple, much as the author field is now. How display of multiple series tags would be handled in say a pub or biblio display would need to be considered.-DES ^Talk 21:29, 22 July 2009 (UTC)

Unfortunately, our nested Series code is already quite complex, e.g. Al's attempts to make empty Series disappear automatically failed because the logic was just too complex. I believe that Al mentioned at some point that implementing support for multiple Series per Title would be an extremely non-trivial proposition :( Ahasuerus 02:36, 24 July 2009 (UTC)

Unlimited Multiple series per title would be complex, but just adding a fixed second series option may not be. [The rest of the comment moved to the Empty Series Deletion section below]. BLongley 17:33, 24 July 2009 (UTC)

I suspect it is the code to display works in series on the summary bibliography page that is the most complex, rather than the code to enter series data for a title, or to store it, or even to display it on a series biblio page. Is this correct? -DES ^Talk 14:19, 24 July 2009 (UTC)

The Series display code is now effectively the same as the Summary display code, so there is no extra complexity there. Marty will be better positioned to comment on the display issues once he comes back from his vacation, but if I recall what Al said about Series correctly, there are other issues involved. Ahasuerus 15:37, 24 July 2009 (UTC)

Empty Series Deletion

The series deletion shouldn't be too hard, judging by the deleted code: the problem was that the only check was that there were no titles left in the series, it also needs a check that there are no sub-series referencing it. BLongley 17:33, 24 July 2009 (UTC)

If I recall the comments that Al made some 3+ years ago correctly, the problem he was running into was automatic deletion of nested Series chains when higher level Series have no Titles. For example, suppose Series A is a super-series of Series B, which, in turn, is a super-series of Series C. Suppose the only Title in these 3 Series belongs to Series C. Assuming that we want empty Series to be automatically deleted, when you delete that last Title, you will also want the Title Deletion approval process to delete all 3 Series since they are now empty. According to Al, the logic that would be required to do this right and account for Titles in other branching Series was quite complicated. Ahasuerus 16:51, 25 July 2009 (UTC)

Moreover, even if we could find a way to do this type of "cascading deletions" easily, our last discussion of this issue concluded that we probably wouldn't want the software to behave that way anyway because deeply nested (albeit almost empty) Series may exist for a reason. Hence the Feature Request to enable manual Series deletion. Having said that, we may still want to modify the software to automatically delete empty Series without touching their now-empty parent Series. Ahasuerus 16:51, 25 July 2009 (UTC)

I'm not sure even that is a good idea. In juggling around a complex set of nested series (think of Star Trek), I can envision an editor removing a title from a nested series, intending that his next edit will place another title there. If the removal auto-deletes the series, then the next edit will recreate the series, but as a simple series with no parent. This is not what is wanted, but the editor might not think/know to check and reset the parent. Also, since a deletion and recreation would break any links from wikipedia via their isfdb series template (which uses the record number), this is to be avoided where possible. -DES ^Talk 17:00, 25 July 2009 (UTC)

Whether it's auto-deletion or manual deletion, I still think it needs the additional check. And I wouldn't cascade delete, particularly if we're going to add more information to the records. BLongley 18:55, 25 July 2009 (UTC)

Sure, the extra check for other Series records pointing to the to-be-deleted Series record is certainly needed if any kind of Series deletion is implemented. As far as DES' points about restricting deletions to manual operations, they make sense, but keep in mind that we have been reusing Series records as a substitute for Series deletion, so there may be a number of bad Series pointers over on the Wikipedia side. Ahasuerus 19:13, 25 July 2009 (UTC)

The bottom line appears to be that we want manual Series deletion implemented first and then we'll see what, if any, automation we want. Ahasuerus 19:13, 25 July 2009 (UTC)

Publication Series

As I understand the "publication series" that have been documented to date, I don't think that a nested model would be needed. I don't know if we have any examples of works belonging to multiple publication series (I don't recall seeing any), but I suppose it is possible, and could be handled by making the field a multiple, as suggested for the main series above.-DES ^Talk 21:29, 22 July 2009 (UTC)

I can't think of any examples where a single publication would go into multiple publication series unless someone wants to use "purple covers" or suchlike to define one. But someone will, I'm sure. BLongley 22:30, 22 July 2009 (UTC)

IIRC, we have some (one or two?) academic works about SF which were published as part of two different Publication series. I recall thinking that it could spell trouble if we ever implement Publication Series support, but I don't recall the details. Ahasuerus 23:23, 22 July 2009 (UTC)

Re: nested series, we have a semi-eligible example, Series:Macmillan's Best of Soviet Science Fiction Series. To quote our Wiki page, "This name is the name of the series in hc form. In tp it is published by Collier Books and is called "Theodore Sturgeon Introduces New Science Fiction From Russia"." Once we have proper Publication Series support -- and assuming we end up with two Pub Series, one for the hardcovers and one the trade paperbacks -- we may want to link the two Pub Series in some way. I doubt it would be terribly important, but it's a thought. Ahasuerus 23:23, 22 July 2009 (UTC)

I may have missed something earlier, but I don't understand how a pub could be in two different publication series. Remember, titles are in author series, but publication series are for, ahem, publications, not titles. So publication series would be linked to pub records, not title records. Or perhaps I'm confused about what's being discussed here. MHHutchins 19:08, 24 July 2009 (UTC)

IIRC, the pub that gave me a pause was some kind of SF-flavored academic book jointly published by, say, Rutgers and Harvard, so it was simultaneously a part of the "Rutgers Review of Rocketship Romance" pub series and the "Harvard Hermeneutics of Haunted Horror" pub series. Ahasuerus 19:32, 24 July 2009 (UTC)

It doesn't strike me as a major problem. We probably haven't got a single feature that doesn't have an exception we don't cope with well. But Publication Series should probably be kept separate from the current series implementation: I can't see much reason to overlap them. I don't think linking is much of a problem either - in the Russian/Soviet SF example there will already be fairly obvious cross-references at title level. BLongley 19:52, 24 July 2009 (UTC)

OK, FR 2827429, "Add support for Publication Series", has been created. Ahasuerus 19:30, 26 July 2009 (UTC)

Poetry series

Currently a series consisting entirely of poems, such as The Dreaming Machine does not display anywhere on the summery bibliography page of the author. -DES ^Talk 23:37, 28 July 2009 (UTC) I have logged FR #2828697 (Poetry series don't display) for this. -DES ^Talk 23:40, 28 July 2009 (UTC)

End of Subsections

I hope these comments are helpful. -DES ^Talk 21:29, 22 July 2009 (UTC)

Sure, all comments are useful! :-) Ahasuerus 23:23, 22 July 2009 (UTC)

Server Issues

There was a problem with the server between approx. 11:30pm and 11:50pm Eastern Time. I captured the state of the database at the time and we'll try to figure out what caused it. Ahasuerus 04:02, 22 July 2009 (UTC)

I was trying to do a three part search on advanced... "peter f. hamilton" = Author, and "god" in title, or "gott" in title. I had a good server response when I opened advanced search in a new tab, and then ~15 second later got no response when I submitted that query. Just FYI, maybe it caused it.... maybe it was just at the same time. Kevin 04:55, 22 July 2009 (UTC)

Server Issues - Part 2

I am sure most of you have noticed that the site is quite slow tonight. Bouncing the Web server and the database server didn't help, so I went hunting for clues. Examining our log of access attempts, I see that we are being hammered by what appear to be multiple bots coming from multiple computers. Examining our list of database transactions, I see that at least some bots are scanning the Author Directory, which means an exhaustive scan of the database, which is obviously very resource intensive. Of course, not all bots admit to being bots, but at least one of them confessed that he was from majestic12.co.uk, a distributed search project.

I am not 100% sure that this is what's causing our problems and I wouldn't know how to address it anyway, but I'll drop Al a line. Ahasuerus 01:28, 24 July 2009 (UTC)

And as soon as I post this message, response time improves dramatically. Hm! Ahasuerus 01:34, 24 July 2009 (UTC)

They (majestic12) claim to offer ways to block or slow down their access, see this page. -DES ^Talk 14:27, 24 July 2009 (UTC)

Patch r2009-13 installed

Patch r2009-13 has been installed on the live server. The following changes have been implemented:

• Bug 2824568 - Fixed errors associated with logging out
• Bug 2824567 - Logging in and out will now redraw the navigation bar and show the correct log in/log out status
• Bug 2824611 - Proper nightly ISFDB banner rotation has been restored
• Bug 1743283 - If you are not logged in and select Clone Pub, you will now be asked to log in and then redirected to the Clone Pub page instead of the Edit Pub page

We hoped to implement the first round of Serials-related changes as part of this patch, but testing uncovered fairly serious issues with the code and we will have to wait for Marty to come back from his vacation (2009-08-02) to address them. Ahasuerus 19:20, 25 July 2009 (UTC)

Fandata, a Dutch bibliography of SF, Fantasty, Horror and other fantastic stories

Dear ISFDB members,

First I want to say, I find your website very good to browse and find details of books en stories.

I have a question to your community. In the Netherlands there is a group of people who are collecting all kind of details about fantastic stories publiced in the Netherlands and Dutch speaking Belgium. We have so far collected details of more than 27.000 books, more than 8000 writers. We have details about almost 40.000 titles (these are titles of books, stories anthologies, etc) and more then 16.000 titles of the original languages (because most of the fantastic work in Dutch is translated) and then I must not forget thousands of magazines and their contents.

But our database, named Fandata, is based on Access 2003 and only open to a limited group of people. We want to take the next step with our database and put it on the internet. But none of our members have the know how to do this in a good manner. We are a community of people who love fantastic fiction, but all are volunteers and we would love to share our knowledge with other people, we are a non profit community. I thought about your database and website. Is it possible that we create a Dutch section of the ISFDB? Or that we use your database and web structure. Because I think it is not wise to integrate our database in yours. Then we create a mix-up of English and Dutch titles and I think this will confuse the searchers. Also is there someone in your community to convert our database in Access to your database structure.

If you community can help us to go to the next step, we would be very gratefull.

Sincerely yours

Marcellus Alias of Marcel van der Rijst

Welcome! I'm glad to hear you like our website. It sounds like you've done very well yourselves: but having worked with Access myself in the past, I can understand the desire to move to something else. Our software is freely available, as is our database structure (and data). We also have several developers that could advise on getting a local copy installed on various types of PC - far fewer that have ever actually deployed it on a true live website though. But if you can fund a website and get someone vaguely technical to run it, I'm sure there would be people here willing to help. BLongley 21:44, 25 July 2009 (UTC)

I can't see a way that we could create a separate section of ISFDB for Dutch titles: we can happily integrate Long fiction titles in Dutch with our own, but here we put the English title first and the Dutch publications under it, unless it was published in Dutch first, in which case we would want the Dutch title first and we would add the English variant as necessary. But I'm sure you have some data we would want. We haven't yet found a good way to cope with short fiction translations yet though. BLongley 21:44, 25 July 2009 (UTC)

I haven't got Access 2003 on this computer, but might on my work laptop. I'll check later and see if I could at least convert the formats for you. Good luck, and keep up the good work! BLongley 21:44, 25 July 2009 (UTC)

(after edit conflict) The database code and structure are available under a Creative Commons License, so anyone may download and install the code, and use it, with proper acknowledgments. See ISFDB:Personal Windows Website or, depending on the OS, ISFDB:Personal Linux Website.

We do already have a number of non-English titles, and plan to expand our support for language designations, so you might want to reconsider integration.

I'm not sure how a "dutch section" would work, but this is the place to suggest and discuss it.

The ISFDB runs on MySQL. It ought to be possible to create a script to extract data from your db and input it into a copy of the ISFDB software, depending on how close your design is to ours.

If you want a site based on the ISFDB code to be truly a dutch site, you would, I think, need to translate all the interface elements from English to Dutch.

The ISFDB is written in Python -- do any of your members know that programming language?

Other editors more involved with the development side of the ISFDB may have better answers for you. You might also want to look at our Development page. -DES ^Talk 21:50, 25 July 2009 (UTC)

BTW I have MS-Access 2000 on my computer. -DES ^Talk 21:53, 25 July 2009 (UTC)

Since your data is currently stored in a database which is not accessible via the Web/Internet, you will need the following in order to put it on the Internet:

1. a domain name -- e.g. our domain name is "isfdb.org"
2. an account with an internet provider
3. software that will expose your data on the Web and a way to convert your current data to the new format
4. someone to configure and maintain this software/database for the foreseeable future

We can help with the software and the database parts since our software is freely available and we have a number of people who understand databases reasonably well. However, the other three items on the list will be harder for us to help with unless we come up with a way to integrate your data into the ISFDB. Let's list them one at a time.

Domain names are quite inexpensive these days -- unless you want to buy a high profile domain -- so that shouldn't be a problem, but keep in mind that Fandata.com is already taken by a fandom directory.

An internet provider is not something that we can help with if you want to have full control of your database. From the technical perspective, we could probably set up another database on our server and share our internet host with you (but I'd have to check) since it wouldn't add much to the cost of running the site. However, you would then be relying on us for your backups, security, maintenance, etc and would make administration considerably more difficult, so probably not a good choice.

Configuration and maintenance. The ISFDB software requires the following tools: MySQL, Python, PHP, and MediaWiki software, including some (optional) add-on packages. If you don't have anyone on board who knows these tools or could learn then reasonably quickly, you will find it hard to configure and maintain a local copy of the ISFDB software. Even you could configure everything and get the site up and running, you would still need to handle the backups, various software updates from the main ISFDB development team, etc.

I don't want to discourage you from trying to install the software locally, but I want to make sure that you understand the challenges involved. If you decide to go that route, you may want to consider finding a local SF fan who has experience in the areas outlined above and who is willing to help with installation and maintenance.

Alternatively, you could consider merging your data with what we have. At the moment, our support for non-English works is quite limited, but we plan to beef it up over the next few months. We have a feature request which outlines how we plan to handle translations and user-defined language settings. Once that feature is implemented, our users will be able to select which language(s) they are interested in, which will let them view only the books/stories in the language(s) of their choice, e.g. Dutch and English. If this meets your needs, then merging the two databases may make more sense, but we would also have to figure out a way for the two communities to work together including ways to address policy issues.

Finally, a hybrid solution is always a possibility. You could start working on a site of your own and then send us a snapshot of your data once we have improved our foreign language support. Then, once we incorporate that snapshot into the ISFDB, you can check and see whether you like the way it looks. If you do, you could then consider merging your data with ours. Regardless of your choice, please don't hesitate to ask questions -- if nothing else, we are a talkative bunch :-) Ahasuerus 00:12, 26 July 2009 (UTC)

Thanks for all your answers. We are now in the looking into and researching the possibilities of going on the net. I will discuse all your suggestions with our group. We are also searching for people who have knownledge of webdesign, hosting and databases in the Netherlands. Hopely we find someone. We are open to your hybrid solution or integration of our database in the ISFDB. The only thing, for me personal would be that I can extract the Dutch titles from all the other languages if I was searching the ISFDB.

Sincerely yours

Marcellus

Chapterbook progress

Shortly before support for adding chapterbook title records was re-enabled (and code to treat them as containers was implemented) we had 70 chapterbook titles and either 1330 or 1430 publications (my memory is unclear), many not linked to a title record. We now have 171 titles and 1510 publications. A few issues have been noted in the chapterbook thread above, but so far I think this is a success. Have a look at ISFDB:Chapterbook cleanup. -DES ^Talk 17:07, 26 July 2009 (UTC)

Merging publisher NEL with New English Library

Would there be any objection to my merging NEL into New English Library? The latter is the more complete name, which is used on all of my verified copies. There are verified copies under both names. MHHutchins 15:06, 28 July 2009 (UTC)

I agree they should probably be merged, but I'd keep the shorter name unless it's leading to confusion. Is it? BLongley 20:05, 28 July 2009 (UTC)

In this case, the page we get all the publication date information from often uses the shorter form, e.g. "First NEL publication", and if we try for "more complete name" then we'll probably encourage more fragmentation as people think "oh, for this one I need to make it "New English Library / Times Mirror". BLongley 20:05, 28 July 2009 (UTC)

I'd prefer more consolidation (at no higher than the imprint level) than further fragmentation, or we'll have to develop variant publisher names and create new screens for those of us that just want to find all NEL books, whether they're "NEL", "New English Library", "New English Library / Times Mirror", "New English Library, an imprint of Hodder Headline" or whatever they are this week. This is what killed the publisher regularisation work - some people like me want simple short entry (so long as it doesn't introduce confusion). Some people seem to want to add the entire publisher hierarchy even though the display software don't allow us to use such usefully, the help doesn't recommend such, the proliferation of Wiki pages for publishers is a pain, and most of us have no real desire to record strings like "Bantam, an imprint of Transworld, owned by Random House, a Bertelsmann company" on one printing that is otherwise identical to the one before the last takeover. BLongley 20:05, 28 July 2009 (UTC)

I strongly recommend the KISS principle: if "Bantam", "Corgi", "Tor", "Forge", "Avon", "Eos", "NEL", "NAL", "DAW", etc, work, keep them. I know some people have found these wanting: e.g. "Tor UK" and "Orbit (US)" for those that can't read the currency symbol on the price field. But I for one have no use for such distinctions being made in the publisher field. BLongley 20:05, 28 July 2009 (UTC)

I Fully agree with Bill. Some people apparently think that the precise form of the publisher name used on a book is significant, and that our existing data on this is or maybe valuable, and are afraid of it being wiped out by regularization. Some people want to personally approve any change that would affect verified pubs. I think that such data is rarely of value, and i don't trust the existing data to be sufficiently noise-free to do much with anyway. i also don't see anyone using it now. But having been strongly criticized for going too far, too fast on this before, i am not going to move on doing anything (as opposed to talking) without a clear and explicit consensus on the issue. -DES ^Talk 20:39, 28 July 2009 (UTC)

I suspect you're referring to the "Del Rey", "Ballantine Del Rey", "Del Rey / Ballantine", etc, regularisation. And yes, that's something that really annoyed me at the time. Now we have the capability to add more checks against destructive edits we can build in protection for such though - "no mass updates that would affect verified pubs" would have saved my blood pressure at the time. BLongley 21:12, 28 July 2009 (UTC)

But in the long term, such will be necessary when the overwhelming consensus is for change, but nobody wants to deal with each individual pub verified by a formerly very active editor. So we get into "when is a verifier no longer considered active?" discussions. But that can be put off a bit longer I think - if we add the protection against affecting verified pubs (all Primary kinds anyway - we still need to define those, and display those properly) then Mods can still do some useful stuff without checking dozens of pubs. For instance, I think we can merge "Golden Wings Enterprises" and "GoldenWings" publishers. I think I'm the person that caused the discrepancy. We have no way of telling that (we're lacking edit history at that level of detail) but I'd simplify it in a heartbeat if I was sure the software would check that it wouldn't stomp over verified publications, carefully constructed Wiki pages, etc. BLongley 21:12, 28 July 2009 (UTC)

It is my view that when we have a consensus for what regularization needs to be done for a given publisher, it will have to be done by mass change no matter how many verified pubs are involved, and how many active or inactive editors have verified them. Frankly i thought we were at that point a year ago, and i still don't see the del Rey changes, or some other mass changes i made at the same time as having any harmful effect, but as having several good ones. I think thqt there needs to be a discussion on a particular publisher, such as MHHutchins is now starting on NEL. Once everyone has signed off (or failed to raise objections), I think a mass change can and should be made, including all verified pubs. After we have done several publishers this way, we may be able to agree on criteria for when publishers can be done without an individual discussion. But I think any process that involves individually checking each verified pub, or that changes only unverified pubs, is useless. -DES ^Talk 22:18, 28 July 2009 (UTC)

I suggest a feature request is made so that moderators can at least get a warning over number of verified pubs that would be affected, possibly listing verifiers affected as well. Maybe listing the affected verified pubs, although there may be many more of those. There are some uncontroversial edits to be made, for sure, and we're pussy-footing around the issue and encouraging proliferation of publishers in the meantime. Coding-wise it doesn't look too difficult but some performance issues might ensue. BLongley 19:57, 5 August 2009 (UTC)

To get back to the gist of my request: every book I have that was published by NEL (mostly pb, maybe a couple of hc) give the publisher as "New English Library". In this case we're not dealing with an imprint that might be effected. As far as I know, there's only one clear publisher for this "brand". Does anyone have a book that only states the publisher as "NEL" without any reference to "New English Library"? (Being American, I don't have an extensive collection of NEL books.) Otherwise I can't think of a reason why the records should not be merged. If you don't agree, give me a reason other than it effecting verified pubs. MHHutchins 20:36, 5 August 2009 (UTC)

I would be in favor of a merge. If I were doing it I would probably make the resulting name "NEL" rather than "New English Library", but that is IMO a minor point. If we have consensus that in general such a merge can be made, I don't think "It would change verified pubs" is a good reason for not making it, nor do i think that a pub-by-pub examination of verified pubs is a useful exercise. -DES ^Talk 20:49, 5 August 2009 (UTC)

We have no clear agreement on what the "Publisher" should be. Some people seem to be going for "Hodder & Stoughton/NEL" or "Hodder Headline/NEL" or "NEL/Mentor Books". I usually go by the spine imprint, as that's the one I suspect people browsing bookshelves will usually see and/or look for. (Does anyone else but me scan entire charity shop shelves in seconds for the SF hidden in with other rubbish? I think I'm 99% accurate based on spines alone.) BLongley 21:28, 5 August 2009 (UTC)

I'm in favour of merging NEL and New English Library, keeping the shorter name. I don't care who owned NEL at the time. I'd be more wary of merging "publishers" when NEL was the publisher and owned imprints like "Four Square". For those, I'd keep the "Four Square" publisher and let the Wiki (and eventually, Improved publisher database support) details cover which imprint was owned by whom, when. The Gollancz/Millenium/Orion stuff is a nightmare though, so I don't think we can establish a general principle yet. And my "use the spine details" would be a nightmare for Pocket Books - they're a mess, with "Simon and Schuster" and "Pulse" recorded on many, confusing publisher and distributor, whereas the spine fragments Pocket into TV tie-ins, juveniles, etc. BLongley 21:28, 5 August 2009 (UTC)

I think what we DO need is a simple way to identify the problem publishers while allowing the simple ones to be merged without excessive work. BLongley 21:28, 5 August 2009 (UTC)

The pub records that show the imprints you mention ("NEL/Mentor", etc.) would not be effected by the merge. If a book is entered as "NEL/Mentor" it will remain "NEL/Mentor". If a book happens to be "NEL/Mentor" and it was entered as only "NEL" it will remain "NEL". Someone later can add the imprint, and that would remove it from the "NEL" listing, which is OK by me as long we can eventually get all "NEL/Mentor" books correctly entered. I personally prefer the longer name, but will go along with the consensus. My only purpose is to get these pubs to be returned from the single search. (Bill, whatever happened to that list of publishers with a single pub record? Wasn't it somewhere in the Wiki?) MHHutchins 21:42, 5 August 2009 (UTC)

Specifically, merging "NEL" with "New English Library" is fine by me. I can't say it's OK by anyone else that's verified any other "NEL" or "New English Library" book though. If you relied on me, a year ago I'd have said they were a pure paperback publisher and all "hc" entries were wrong! That's why I suggest adding software support so anyone doing such a big merge at least knows who would be affected, or should be consulted. I guess I could create something offline to check in this particular case. But this shouldn't create a precedent. BLongley 22:16, 5 August 2009 (UTC)

The list of publishers with numbers of publications can be recreated, I think that was only sent to Kraang though, I can't recall if/where it was published here. But again, I'd prefer people have up-to-date info direct from the database rather than rely on people posting such on request from old data. BLongley 22:16, 5 August 2009 (UTC)

First of all, YES, please merge. Second, belatedly weighing in on the length-of-name aspect of this: Names matching what the books are likely to have, whether that is an acronym or spelled out, seems to me to be better, especially for the more casual user. Less of a problem on the data entry side and more likely to produce expected search results. The "as it appears on the title page" rule for titles and author names should be the default here, too, in my opinion. It's clear and easy to remember. --MartyD 21:50, 5 August 2009 (UTC)

I would follow the "shortest and simplest commonly known name" rule my self. Tor has sometimes used "TOR", sometimes "Tor", sometimes "Tor Books", etc. I would convert all of these to simply "Tor". I would convert "Pocket Books" to simply "Pocket". I would convert "Baen Books" to simply "Baen". This would help to establish the principle that a change in the way a publisher prints its name on its books, while the publisher as an organization remains unchanged, is not significant. In the NEL case, they use "NEL" on covers and spines I think, but "New English Library" on title pages. But if people prefer a different rule, and that will let us go ahead with merging, i won't argue. -DES ^Talk 22:18, 5 August 2009 (UTC)

Marty, unfortunately, "Title page" often doesn't work for the Publisher name. When it's clear, it's often at such a high level that it doesn't distinguish between when it was published as a general book, a YA book, or a Children's book, etc: see Puffin or Pelican Books books that are published by Penguin. BLongley 22:35, 5 August 2009 (UTC)

When it's unclear, it's even worse. I have many books where the title page just shows a star-shaped logo with a "G" or an "M" in the middle - this means "Gollancz" or "Millennium", but both were imprints of "Orion", or "Millennium" was an imprint of "Gollancz"... :-( As DES suggests, "shortest and simplest commonly known name" would be good, but I want the lowest level (imprint) recorded unless that causes problems. The "Roc / NAL / Penguin (Putnam?)" stuff just annoys me. BLongley 22:35, 5 August 2009 (UTC)

(unindented)My preference is "NEL" and as soon as I'm finished with the 2004 & 2005 clean up of non SF I'll return to the publishers. The nice long names will help in constructing the imprints history.Kraang 00:55, 6 August 2009 (UTC)

Verified pubs mention in canned welcome to new editors message

Twice in the last week with two different new editors I have been involved in issues concerning changes to my verified pubs. I have no idea how many other changes have been made to them without my knowledge. It is not the fault of the new editors because they have no way of knowing the policy for dealing with verified pubs. IN FACT we actually have no policy except on an individual ad hoc basis which is often posted on individual talk pages. Perhaps we should all have such a policy statement and mention that new editors should check talk pages of the verifiers.--swfritter 15:51, 28 July 2009 (UTC)

Sounds like a good idea. There should be a stated policy. The moderators are the only defense against changes to verified pubs, but sadly, there are many pub records that have been verified by long-absent editors. In those cases, it's a matter of doing independent research and accepting the edits, or rejecting them outright and upsetting a new editor. At least with a policy to point to, it might soften the rejection. MHHutchins 16:03, 28 July 2009 (UTC)

In such a case, I will often try to do the research if it can be done online, but no moderator is obliged to go that far, IMO. If I do the research and approve the edit, I will still notify the verifier, even if inactive, or make sure that the new editor does so. -DES ^Talk 16:36, 28 July 2009 (UTC)

Many of those absent editors are on my and others watchlist so it still helps to put a notice on their talk pages. In one of the cases I mention above it was my fault because I did an inadequate job of describing possible solutions to a problem.--swfritter 16:12, 28 July 2009 (UTC)

(after edit conflict) I was under the impression that we have a tacit policy that moderators shouldn't approve such changes without discussing them with the new editor, and either notifying the verifier or making sure that the new editor has done so. And further that such edits won't be approved unless the verifier has responded, or the moderator is confident that there will be no problem, perhaps after checking the verifier's individual policy, if any. Perhaps this should be added to Help:Screen:Moderator? I was under the impression that, by default, we didn't make additive changes to primary verified pubs without notifying the verifier, possibly after the fact but not long after; and that we didn't make "destructive" changes (changes that remove or alter recorded and presumably verified data) without asking the verifier first, if the verifier is active. This may be modified by the individual policies of individual verifiers -- in particular a few have asked not to be notified of such changes as adding cover art or OCLC record numbers. But unless a statement to the contrary has been made, I understood the above defaults to apply. Help:How to verify data#Replacing a Primary Verifier more or less assumes this default, and Help:How to verify data#Primary Verification says "It is a matter of courtesy to inform the verifier of changes you make to his or her verified pubs and it is strongly encouraged that you notify the verifier first if the change is particularly significant." Perhaps this should be strengthened, and put into a new section Help:How to verify data#Making Changes to Verified Pubs? -DES ^Talk 16:17, 28 July 2009 (UTC)

Of course, it is not fair to expect newcomers to know this, or even to know to check a verifier's user page or talk page to learn his personal policy. We might put a link to Help:How to verify data in the welcome template, but I think it has to be mostly up to the moderators who handle the early submisison to instruct newcomers in this and similar matters. That's how i learned. -DES ^Talk 16:17, 28 July 2009 (UTC)

I have just made this change to Help:How to verify data: do people think it helps clarify the policy? Is it something we can point to in educating new editors? -DES ^Talk 16:27, 28 July 2009 (UTC)

What do people think of adding the following to the welcome template?

Please be careful in editing publications that have been primary verified by other editors. See Help:How to verify data#Making changes to verified pubs. But if you have a copy of an unverified publication, verifying it can be quite helpful. See Help:How to verify data for detailed information.

Will this help cover he situation? -DES ^Talk 16:34, 28 July 2009 (UTC)

Like it. I think I need to start putting more policy pages on my watchlist.--swfritter 17:09, 28 July 2009 (UTC)

Done. Can always be revised if people dislike it or come up with better wording. -DES ^Talk 19:31, 28 July 2009 (UTC)

I like it. rest of comment moved, see below BLongley 20:30, 28 July 2009 (UTC)

Comments on the development process moved to #Development discussion (split out from Verified Pubs discussion) below -DES ^Talk 15:20, 29 July 2009 (UTC)

(Unindent) Reference:Primary also documents our existing policy. It says:

"If adding data to a publication primary verified by someone else, you should notify the original verifier on his or her talk page, unless that verifier has indicated otherwise."
"If you are changing substantive data (not changing a blank to a non-blank field), it is usually a good idea to ask the verifier in advance."

Do people think that Reference:Primary, Help:How to verify data, ISFDB FAQ‎, and the newly revised Template:Welcome together are enough of a policy statement on this matter? Should a mention be added to Help:Screen:Moderator? -DES ^Talk 22:47, 28 July 2009 (UTC)

FAQ changes

I made several changes to the ISFDB FAQ, first in light of the discussion about verification above, and then adding other things that seemed to me to be missing. Please take a look and make sure that you agree with these additions and changes to the FAQ, if you have a chance. -DES ^Talk 21:00, 28 July 2009 (UTC)

Just made a small change to one of the responses. MHHutchins 14:57, 29 July 2009 (UTC)

Yes, that's an improvement. Thanks. -DES ^Talk 15:07, 29 July 2009 (UTC)

Lots of good stuff added! -- Dave (davecat) 15:25, 29 July 2009 (UTC)

Development discussion (split out from Verified Pubs discussion)

Thread split off from #Verified pubs mention in canned welcome to new editors message above. -DES ^Talk 15:22, 29 July 2009 (UTC)

Another thing that could be done (code change, but one we're looking at centralising anyway) is reminding editors of a verified pub that they should have considered leaving a message on the verifier(s) talk page(s). But I know I'm already getting tired of the "Your submission must be approved by a moderator before it enters the database" nag (I know, I added it - and the addition of multiple verification support makes it worse (that's my fault too)) and probably the best way forward in the end is to set up all nag warnings as something that can be switched off when an editor has finally got the point and doesn't want such warnings any more. BLongley 20:30, 28 July 2009 (UTC)

Another item for User preferences, once we implement such? -DES ^Talk 20:32, 28 July 2009 (UTC)

Yes. We're beginning to get into big design changes though, and we should probably start small with a simple user preference like "Don't show me the reminder about a Mod needing to approve my edit, I have found my talk page now". That might be a simple "Don't show me this warning again" option at first, progressing to a final "Edit all my options, as I obviously need reminders of some things now I can't tell all these Bills and Daves apart". BLongley 20:43, 28 July 2009 (UTC)

I don't disagree, although a general "User Preferences page" doesn't seem so huge, it is what might go on it that can be huge. By the way, perhaps your additional nag for talking to a verifier could be part of FR 2805054 Better submission feedback to editor? -DES ^Talk 20:49, 28 July 2009 (UTC)

It could, but that is a BIG change. Remember, we developers so far haven't (AFAIK):

• Changed the database structure at all
• Mass-changed any data at all
• Changed any submission formats in the XML
• Changed any process that gets a submitted edit into a final update to the database
• Created any new screens

I think we've done a lot of good work (more appreciation of such always welcome though!), but we haven't done anything really dangerous yet. Marty is brave enough to change some core library functions, I haven't been. I've reenabled some support that used to be there for Chapterbooks, but haven't really changed much. I've added much new stuff, mostly things that help mods or educate editors: but that's all links to existing capabilities. The big risks are yet to come! BLongley 21:39, 28 July 2009 (UTC)

We mass-changed 1,000+ Review records with missing Author names a few patches ago, but otherwise Bill is absolutely right: we have been nibbling around the edges and staying away from major changes. I think we are getting more confident, though, and will be in a position to start making small changes to the database (e.g. new Series fields) soon. Oh, look, a big red button! Wonder what will happen if I push it?.. Ahasuerus 14:18, 29 July 2009 (UTC)

Thanks for mentioning about changing the review records. I'd been holding off creating variants for review records because of the bug that dropped the authors from the variants. Did I miss the notice that this had gone into effect, or was it in some techno-speak that went over my head? :-) Thanks anyway. MHHutchins 14:40, 29 July 2009 (UTC)

The software fix went live in Patch r2009-04: "Bug 1743292 Fixed creating Variant Titles for Reviews and Interviews, which currently results in Author-less Titles." The mass change of all affected Reviews (and a manual fix of all Interviews) was done in Patch r2009-11: "All but 1 pseudonymous review records which were missing Reviewee fields have been fixed. The last one is being investigated."

I try to make these announcements as non-technical as possible, but I suspect that they may get lost in the sea of other discussions on the Community Portal. Should we create a special page for this information or perhaps use the Recent changes page? Ahasuerus 15:01, 29 July 2009 (UTC)

Thanks for the clarification. I like the idea of having one place to look for the changes. But I thought the Recent Changes page (which I check constantly) only records changes in the Wiki, not changes in the db. Why not record them on the What's New page which I rarely check as it's hardly ever updated? MHHutchins 15:26, 29 July 2009 (UTC)

(after edit conflict)A separate page might avoid things being lost in the mass, but the advantage of using this page is that most people already watch it, a new page might not be looked at at all by the people we want to reach. Perhaps a new page (another sub-page of Development?) with the announcements here reduced to pointers? I'm not sure. -DES ^Talk 15:27, 29 July 2009 (UTC)

Sorry, I meant to link to What's New aka "Current Events" :( It was used for announcements in the past, but typically not for the low level stuff that we are talking about about here. We also maintain Development/Recent Patches, but it's more technical and the descriptions are a little cryptic, so you often need to go to the original Bug/Feature Request to understand what has changed. Perhaps we could beef up the "Description" column and make it more detailed and less technical? Ahasuerus 15:53, 29 July 2009 (UTC)

I think we should update What's New a little more, but not with every fixed bug or implemented feature. Development/Recent Patches is useful, but it doesn't group the changes into patches in the way the announcements on this page have done. But I can't see, on thinkign about it, having another page that is a near dup of Development/Recent Patches in a slightly different format. Beefing up Development/Recent Patches and updating What's New a little more often might be the best approach. I'm not sure. -DES ^Talk 16:24, 29 July 2009 (UTC)

[unindent] As long as the highlights of the changes and fixed bugs are listed, it's fine with me. The recent update to the What's New page tells me all I need to know. I'd suggest all moderators place a watch on that page. Thanks for listening. MHHutchins 17:11, 29 July 2009 (UTC)

One thing that we should probably be doing is updating help to match the code changes. For instance, I've concentrated on making my life as a moderator easier, so there's a lot more links Moderators can use when reviewing submissions. Those probably mean a few updates to Help:Screen:Moderator are needed. Hopefully all Mods have that on their watchlist? (Actually, thinking how long it took to spread the news about dumpxml and hardreject, maybe not. And thinking further, should we be making those tools more easily available rather than having to manipulate URLs?) BLongley 18:34, 29 July 2009 (UTC)

Yes! :-) Ahasuerus 18:54, 29 July 2009 (UTC)

I use dumpxml a lot during testing/debugging, and it's totally non-destructive, so I think I might look at that soon. hardreject obviously does throw away an entire submission so might need to be placed in a "last resort" area. I haven't seen a need to use it in quite a while though, so that can be discussed at leisure. BLongley 19:09, 29 July 2009 (UTC)

I have not had many occasions to use dumpxml, but I did use it in figuring out what was going on in the italics submission discussed above. A button to switch to it would be nice. -DES ^Talk 20:49, 29 July 2009 (UTC)

True, a "View raw submission data as XML" button would be useful. As far as "hardreject" goes, we could make it available as an option when the regular submission display logic errors out, but it's probably better to display a message telling the reviewing moderator to bring the issue up on the Community Portal so that the development team could investigate the problem. Ahasuerus 21:08, 29 July 2009 (UTC)

Re: "hardreject", we may want to add a link to it if a Publication Edit submission points to a non-existing (usually merged) Title. When this happens, the approval screen no longer errors out, but it gives you a big red "Error: record NNNNNN is not valid" error and no way to get around it. Ahasuerus 12:47, 31 July 2009 (UTC)

FR 2830313 "Add the ability to view submissions as raw XML" and FR 2830316 "Add the ability to "hard reject" bad submissions" added. Ahasuerus 12:56, 31 July 2009 (UTC)

I'm fine with adding both dumpxml and hardreject to the UI but have also been mulling over ways to clean up the left navbar as at present I end up often scrolling the page to get to a navbar option. For example, when viewing a publication I've never used Logged In As and of Other Pages: I only use Home Page. We could make the ISFDB banner and that folder thing link to the home page which would allow us to drop the top two sections of the navbar or, as they tend to be the same for all pages, to put them in a horizontal navbar and to move Policies plus License into the footer. --Marc Kupper|talk 04:28, 7 August 2009 (UTC)

Another thing I've noticed that may not be so obvious to moderators is that the left nav bar after a submission is relatively useless to a non-moderator, where a next step is likely to be another submission. One has to navigate back to the home page to get the menus. --MartyD 12:10, 8 August 2009 (UTC)

Patch r2009-14 live

Patch r2009-14 has been installed. The following changes have been implemented:

• Bug 2818651 - Fixed the misspelling of the word "Pseudonym" in the Advanced Search drop-down lists. Temporarily disabled the "AND NOT" radio button in the Advanced Search screen to prevent Python errors. We will implement the "AND NOT" functionality once we figure out how to do it without slowing down the server.
• Bug 2818279 - Fixed an error which occurred when merging Author records on the second and subsequent pages of the Advanced Author Search.
• FR 2803247 - Added a new column which displays the Pseudonym flag to Author search results in regular and Advanced Author searches.
• Bug 2828187 - Fixed the display of Awards Bibliographies for Authors with apostrophes in their name.
• Bug 1743274 - Disallowed the creation of a canonical Author name if there is an Author with the same canonical name on file.
• Bug 1950102 - Disallowed double quotes in Canonical names when using Author Edit. We will also need to add logic to automatically convert double quotes to single quotes when editing Titles and Pubs.
• FR 2797936 - The Storylen field (shortstory, novella, novelization, etc) is now displayed in the Title bibliography page.

Please post reports of any issues here - thanks! Ahasuerus 00:59, 31 July 2009 (UTC)

There is an issue with the Pseud flag in author searches. For example Robert A. Heinlein shows "Pseudonym". I presume this is because of "# Used As Alternate Name By: Frederik Pohl , Judith Merril" but it is possibly confusing to most users. This change makes the urgency of being able to remove incorrect Pseudonym flags greater, IMO, and we probably need some sort of flag for the cases where a name is both the canonical name of an actual person, but was also used as a pesud by some other person. Such cases should probably be marked differently in this column than pure Pseudonyms. -DES ^Talk 15:13, 31 July 2009 (UTC)

The situation with Heinlein was caused by someone thinking there was sufficient evidence for making him the ghost editor of an anthology. If it were left to me, the information could have been placed in the notes, but that's not reason enough to make Heinlein a pseudonym of Merril and Pohl. When an editor makes a submission making a canonical name into a pseudonym, there should be a red flag, and a discussion should begin about the worthiness of making such a non-reversible decision. In the case mentioned, we should have made Merril and Pohl uncredited editors. MHHutchins 15:58, 31 July 2009 (UTC)

Yes I understand that, but the query result is still confusing, and IMO makes it more pressing to be able to remove ill-judged Pseudonym relationships. Also, whether it is true in Heinlein's case or not, there are cases (V. C. Andrews comes to mind) where a name is both a canonical name and a pseudonym. The current flag in the search results will label all such names as Pseudonyms, and this will not help people looking for the "real" (canonical) name for such authors. -DES ^Talk 16:09, 31 July 2009 (UTC)

Enabling Pseudonym deletion is definitely a high priority, but it will likely require changes to the submission queue format and possibly other areas like the Web API, which is why it has been pushed back. I expect that we will get to it in the next month or two as we get more comfortable with making submission and database changes. Ahasuerus 16:42, 31 July 2009 (UTC)

As far as the current search behavior goes, it can certainly be changed, but first we need to decide what the desired behavior is. Consider the case of Ed Emsh and Emsh. They are both marked as pseudonyms -- legitimately so -- yet they have dozens of non-VTs Titles waiting to be cleaned up. There is no way of telling whether an Author record which is both (a) labeled "pseudonym" and (b) has non-VT Title records is just waiting to be cleaned up or whether it's one of those rare occurrences when a name has been used both by a real person (V. C. Andrews) and by a posthumous ghost-writer. The most we can do is display some kind of "Pseudonym but has non-VT Titles" flag in the "Pseudonym?" column. Ahasuerus 16:42, 31 July 2009 (UTC)

The problem is that someone searching for "Emsh" may see both Ed Emsh and Emsh marked as "pseudonym" and assume that neither is the correct answer, which may be incorrect. -DES ^Talk 16:59, 31 July 2009 (UTC)

We have a number of spurious Pseudonym relationships set up for artist records (including a few Emsh-related ones) and as long as these relationships exist in the database, they will be reflected in search results and on Author Summary pages one way or another. Once the underlying data has been cleaned up, most of these issues will disappear and we will be left with a few "V. C. Andrews"-like cases. Ahasuerus 17:20, 31 July 2009 (UTC)

Cleaning up the existing data would be very good, of course. (And I thing we need clearer standards for artists, as opposed to authors.) But I fear that as new authors and new data are added, there will always be authors in a state of transition, with Pseudonym relationships created, but VTs not yet assigned, or alternatively, authors disambiguated. -DES ^Talk 19:20, 31 July 2009 (UTC)

I think the ultimate answer may be to store a flag as part of the author metadata indicating that a name is both canonical and a pseudonym. Obviously, as a DB change, that won't happen overnight. -DES ^Talk 16:59, 31 July 2009 (UTC)

Yes, a flag that the display software would be able to use to generate a "This author is a real person, but the name has also been used by other writers" message. Ahasuerus 17:20, 31 July 2009 (UTC)

Exactly! -DES ^Talk 19:20, 31 July 2009 (UTC)

Until then, a "Pseudonym but has non-VT Titles" flag (with better wording than that, if any of us can think of such), would IMO be a good idea -- might help find authors in need of cleanup, too. -DES ^Talk 16:59, 31 July 2009 (UTC)

Think hard, Mr. Moto! :-) Ahasuerus 17:20, 31 July 2009 (UTC)

I will. -DES ^Talk 19:20, 31 July 2009 (UTC)

OK, I have reviewed the pseudonym creation code and it doesn't look too bad, so we may be able to implement pseudonym deletion sooner rather than later. I'll post the technical details on the Development Talk page. Ahasuerus 18:43, 31 July 2009 (UTC)

Great. -DES ^Talk 19:20, 31 July 2009 (UTC)

(Unindent) There's a problem with the check against creating a new canonical author that already exists. I tried updating "Marie O'Regan" to add her website http://www.marieoregan.net/ and get the "Error: Canonical name 'Marie O’Regan' already exists, duplicates are not allowed." even though I'm not actually creating a duplicate. BLongley 20:52, 31 July 2009 (UTC)

Thanks, I will check the code in a few hours. Ahasuerus 21:11, 31 July 2009 (UTC)

It turns out that this is an old problem with apostrophes handled differently when entered in a form vs. retrieved from the database. All moderators encountered it in the past when the "Proposed" column in the submission approval screen would show a value even though it was the same value as in the "Current" column. The problem was fixed in most cases some time in 2008, but it was overlooked in this case, presumably because it was harmless prior to the last change. I'll fix it later tonight. Ahasuerus 22:01, 31 July 2009 (UTC)

I think the same issue affects the notes field. Can you take a look at that also? -DES ^Talk 22:28, 31 July 2009 (UTC)

Bug 2830636 "Apostrophes make the Notes field appear as changed" has been created. I'll take a look at it, but apostrophes are nasty critters in our environment (between Unicode, XML and Cthulhu knows what else) and Notes have quirks of their own, so it's hard to tell how long it will take to fix. As I recall, it took Al a few months to figure it all out and he is much better than me at this coding business. Perhaps other developers (Marty when he comes back early next week?) will have more luck with it. Ahasuerus 00:16, 1 August 2009 (UTC)

(unindent) Patch r2009-15 has been installed. Its only purpose in life is to fix the problem with editing authors who are (un)lucky enough to have apostrophes in their canonical names. Hopefully this will be the last time we hear of this meddlesome bug. Ahasuerus 02:52, 1 August 2009 (UTC)

Seems to work on the 20 or so authors I tried it on. BLongley 11:04, 1 August 2009 (UTC)

Help:Conventions Opinions sought

I have just created Help:Conventions. It is a draft page. I would like opinions on it before linking it to various places in the wiki help, and perhaps adding it to {{Welcome}}. -DES ^Talk 00:39, 5 August 2009 (UTC)

I think it's a good idea. We use a number of conventions, some borrowed from Wikipedia and others homegrown. Even though we tend to think of them as self-explanatory, they may not be obvious to new editors. I have reworded a few paragraphs, but I don't think it contains anything particularly controversial substantively.

multiple sub-sections moved to Help talk:Conventions. -DES ^Talk 19:59, 7 August 2009 (UTC)

Move this to the Conventions's talk page

Can we move this block entire discussion about the content of Help:Conventions to Help talk:Conventions and to just leave a link to it here? That way the history of discussion about that page is on it's talk page rather than eventually being buried in the Community Portal archives. --Marc Kupper|talk 19:49, 7 August 2009 (UTC)

Will do. Good idea. -DES ^Talk 19:53, 7 August 2009 (UTC)

Move done. See Help talk:Conventions. -DES ^Talk 19:59, 7 August 2009 (UTC)

Tone down the Submission warning?

Now that it's novelty has worn off, I find the enormous warning about submissions needing moderator approval to be jarring. I'm not sure what to suggest -- smaller font or placing it at the bottom, perhaps -- but I wonder if anyone else shares my reaction.... --MartyD 11:54, 5 August 2009 (UTC)

It isn't bothering me. -DES ^Talk 14:47, 5 August 2009 (UTC)

It so happens that I am in the process of cleaning up our submission scripts and one of the things that I am doing is centralizing all occurrences of this message. Once I am done, it will be easy to change its appearance. Going forward, we need a "User preferences" page which will, inter alia, let the user turn off this message. Once we have this ability, we can add "(You can turn this message off in User Preferences in the navigation bar on the left)" to the text. Ahasuerus 14:50, 5 August 2009 (UTC)

No bothered by it. Actually like it. Thanks, Harry. --Dragoondelight 15:07, 5 August 2009 (UTC)

After the first hundred or so I don't even see it anymore. Willem H. 15:28, 5 August 2009 (UTC)

It's primary purpose was for new editors. It doesn't bother me, so it personally doesn't matter if we have the ability to remove it using a user preference option. MHHutchins 18:19, 5 August 2009 (UTC)

It's supposed to be jarring, but then the "New Messages" changes are even worse (IMO) and seem to have been more successful. It might be wiser to direct people to their talk page only after there is something there? Or does leading people to the Wiki immediately still sound like a good idea? (We'll never know how many people get put off by the lack of an instant visible change they've made, so getting them to wander the Wiki for a bit might still be good.) BLongley 18:35, 5 August 2009 (UTC)

I am not complaining that it's there, only that at 6am I'd rather be told quietly instead of being shouted at, as it were. I wholeheartedly agree that its presence and twofold purpose is good and desirable. --MartyD 19:28, 5 August 2009 (UTC)

I'm happy to consider its removal, your change seems to have had a larger effect (OK, that's based on a sample of one new editor answering DES) and I'm not protective over what must have been... ooh, several minutes of coding on my part. ;-) I can wait till "User preferences" gets started, I don't think I'd try to consider the user's local time before selecting a font-size, unless some partially-sighted editor is having their screen-reader disturb the neighbours. If "User preferences" doesn't happen soon, then maybe starting with a gradual "they haven't selected a preference as we haven't coded it yet, let's at least start recording some data against the user so we can tone it down after a few viewings" or such might be in order. BLongley 19:44, 5 August 2009 (UTC)

If we can detect the count of wiki edits by an editor, and reduce font size of the message when that count is above some small threshold value (10? 5?) that might be a good idea. if user preferences is to come along fairly soon, that would IMO be better. I don't know if it is easy to query the wiki for this info. -DES ^Talk 20:35, 5 August 2009 (UTC)

Getting ISFDB to recognise Wiki changes is something beyond me, I've only just got to the stage that I think I understand most ISFDB data changes. And I don't fully understand the display issues at all. The Wiki data will remain a mystery to me even longer as I think only two people have offline Wikimedia installations to work with, hence my request that all wiki-related feature changes allow us to still link to the live Wiki - would you trust me to test a change if I said that I'd got a "404" error message that looked OK otherwise? BLongley 22:58, 5 August 2009 (UTC)

Could we use a db element like submission count? It would seem like most editors would have gotten to their talk page before they have made a 100 to 200 submissions although there may have been cases where new editors have taken a little longer. It's the rare new editor who would not have gotten at least one submission placed on hold before that.--swfritter 23:34, 5 August 2009 (UTC)

Yes, we could, but also keep in mind that Marty has experience working with the Wiki software and has already made some changes here, so it's not outside of the realm of the possible. We just need to decide how we want our Wiki software to behave and then run it by him to see how easy it would be to implement. Also, once we add User Preferences, this change can be made outside of the Wikiworld. Ahasuerus 00:35, 6 August 2009 (UTC)

MediaWiki maintains a (Wiki) edit count for each user (in mw_user.user_editcount). I agree, though, that preferences would probably be a better way to go. --MartyD 01:33, 6 August 2009 (UTC)

Use of edit count would IMO be a stopgap, pending implementation of a user preferences facility. -DES ^Talk 01:36, 6 August 2009 (UTC)

"In July, Interzone became the longest-running UK sf magazine by number of issues"

The claim is from the latest Ansible and was something I immediately wanted to check here. I can't see how a user could do such though: what with Editor merging by year, you can't do it in Advanced Title Search by EDITOR records, and there's no way to search by title type of MAGAZINE in Advanced publication search. BLongley 20:09, 5 August 2009 (UTC)

Hm, that looks like a bug, doesn't it? Ahasuerus 20:51, 5 August 2009 (UTC)

I'd be polite and say it's a "Missing Feature" from advanced publication search. I can understand the reasons for Editor Record merging abuse. BLongley 22:47, 5 August 2009 (UTC)

Checking Schema:pubs, I see that I was wrong: "ptype" stands for "Publication Binding Type", not "Publication Type". The latter is stored in "ctype". Bug 2833930 has been changed to a Feature request. Ahasuerus 21:44, 7 August 2009 (UTC)

Am I the only person that would like such a facility, and if not, how should it be implemented? BLongley 20:09, 5 August 2009 (UTC)

The number is usually recorded in the Wiki, but it's much harder to find all related magazine issues in the database proper. In a way, this is intentional since we didn't want our users to get lost on a page with 700+ issues of Analog, hence EDITOR merging. Still, there have been occasional requests to create a screen that would:

• display the magazine-specific information that is currently stored in the Wiki magazine pages; and
• be accessible from any issue of that magazine

This is probably a desirable "end state" goal. A possible palliative solution would be to add an "Other issues" field to all Magazine records that would take you to the currently selected magazine's Wiki page. Ahasuerus 20:51, 5 August 2009 (UTC)

(moved here to preserve continuity after an edit conflict) Might be useful. A publications search seems the obvious way, since magazines normally have only one pub per issue. Put the present Publication form in the advanced search seems to have issues (er so to speak, no pun intended): I get a single page of results for a search on "Analog Science fact"; well maybe that is correct, as I get multiple pages on just "Analog". It is unfortunate that the first page doesn't show the total count of responses, as most basic searches do. -DES ^Talk 20:45, 5 August 2009 (UTC)

Possible bug in series display within a publication record

I've noticed this over the past couple of years and wondered if it has drawn anyone else's attention. When a title is placed into a series, it would normally display the series after the title when it is a content of another publication. BUT, if it's a variant (because of either title or author), you can't have both records in the series, because both would show up on the series list. So common practice is to make the parent record in the series and the variant record not. BUT, if you do this, the series is not displayed in the record in which the title record appears as a content. Here's an example of one I did this morning. This first content record was published as by "Richard Rosa" which has been made into a variant of "Dr. Richard J. Rosa". The parent title record is in the series "Editorial (Analog)", but it doesn't display in the magazine record. Now if I place the child record (the one credited to "Richard Rosa") the series is displayed in the magazine record. But then both records will appear on the listing for this series. Any way to get around this? MHHutchins 14:47, 7 August 2009 (UTC)

Another thing: if I keep the child record under the series, it doesn't display as a series on the parent record's author summary page. MHHutchins 14:53, 7 August 2009 (UTC)

It's a known issue documented in Feature Request 2813393:

• At this time the Contents section of the Publication display screen shows the Series for each displayed Title. It also display the parent Title for any VTs. However, it doesn't display the Series of the parent Title for VTs. We need to add this information to the display.

The change is not controversial, so I expect it will be implemented over the next few months. Ahasuerus 15:04, 7 August 2009 (UTC)

Leading, trailing and double spaces

I am in the process of changing our editing scripts to automatically convert double quotes in Author names to single quotes. I am also cleaning up these scripts in other ways, including stripping all leading, trailing and double spaces in all fields. Are there any fields where double spaces should be allowed? Should I allow them in Notes so that editors could enter two spaces after periods, as some apparently do? Ahasuerus 17:35, 7 August 2009 (UTC)

I see no value to retaining leading or trailing spaces, except in search strings, where they can be useful. I don't particularly care about double spaces, and would not object to a convention that we we treat them as single spaces in future, but I don't see that they do any particular harm in the Notes field. -DES ^Talk 17:47, 7 August 2009 (UTC)

OK, I will leave the Notes fields alone then, thanks! Ahasuerus 15:19, 8 August 2009 (UTC)

Geocities going away (and what we can do about it)

Geocities, once a popular free hosting area which ISFDB used in 1995 for the first 2 days of its existence (until we went over the bandwidth limit ;-) will be shut down on October 26, 2009. If you are aware of any useful SF bibliographies still hosted by Geocities, please post them here and I will archive them. Many SF sites formerly hosted by Geocities have moved to other locations, but some are still there, e.g.:

• Christopher Pike's site
• Parsec Science Fiction

These sites may remain available via the Internet Archive/Wayback Machine, but it's not 100% reliable, so if there is anything valuable that you would like to preserve, let's grab them before it's too late. Ahasuerus 15:18, 8 August 2009 (UTC)

These sites seem to have some possibly useful stuff.

• Fantastic Reviews - saved
• Made in Canada
• Cathy Cupitt's Bibliography
• Barry Malzberg Bibliography
• Connie Willis page
• Ann K. Schwader page
• Ed Gorman
• Jarl Szydlow / Mary Vigliant (Mary Vigliante Szydlowski)
• E. C. Tubb page
• Andre Norton Bibliography
• Tolkien Biblio
• Edward P. Berglund
• Hal Clement
• Clifford D. Simak
• Sarah Totton
• Evelyn C. Leeper
• Keith Laumer
• Keesa Renee Dupre
• Octavia Butler
• Greg Bear (and links to Larry Niven, Greg Benford, ERB, Asimov, McCaffrey)
• Robert Heinlein
• John Varley
• Arthur C. Clarke
• Margaret Atwood
• Kynan Hale
• Paul Preuss

I've not checked any of them deeply though. BLongley 17:23, 8 August 2009 (UTC)

Thanks, I'll check them out and download what I can! Ahasuerus 01:08, 9 August 2009 (UTC)

I am archiving them one (or three) at a time and will update the list above accordingly. Ahasuerus 19:15, 9 August 2009 (UTC)

Also The Evening News - lots of non-genre stuff, but also lots of first-British-Publication Genre stuff. How to filter it, I don't know yet. BLongley 20:16, 9 August 2009 (UTC)

Apparently they still have bandwidth limits and my downloads keep erroring out on larger sites. There are ways around it, but they are somewhat painful. Deplorable. Ahasuerus 03:18, 10 August 2009 (UTC)

New cover templates for multi-artist covers

I have created {{Cover Image Data3-2}}, alias {{CID3-2}} alias {{C3-2}}, for use on cover images that have two credited artists, either joint artists or separate artists when both covers of a double are shown in a single image.

I have also created {{Cover Image Data3-3}}, alias {{CID3-3}} alias {{C3-3}} for any cover images with three credit artists.

Both are closely based on {{Cover Image Data3}}. Both put the image wiki page into categories for each artist, plus a combined works category. See Image:PLNTXLE1966.jpg‎ for an example of a 2-artist image. Created at Bluesman's request. I hope these will be useful. -DES ^Talk 20:33, 8 August 2009 (UTC)

Patch r2009-16 installed, first round of Serial changes goes live

Patch r2009-16 has been installed on the live server. It includes two changes:

• Feature Request 2823387. The first part of the improved Serial support is now live.
• Bug 2799421. n When running and Advanced Search with multiple parameters, one of the parameters is no longer ignored after page 2.

Please note that you can now make Serial records into VTs of their parent novels and the results will look reasonable on Summary Bibliography pages. Title level bibliographies have some display quirks at the moment, but they will disappear when we are done with the Serial migration.

The next step for the Great Serial Migration is to generate a list of Serials that are currently set up as VTs. In many cases these VTs are linked to a placeholder NOVEL Title -- these need to be re-linked to the main canonical Title record and the placeholder needs to be deleted. I will create a Wiki page and populate it with a list of currently existing Serial VTs shortly. There are about 360 of them, so it shouldn't take us more than a few days to clean everything up. In the meantime, we will write and run a script which will find all non-VT Serial records that have matching Novel records and establish a VT relationship between the two. Once all of this is done, we will disable the "lexical match" logic and celebrate :-) Ahasuerus 04:26, 9 August 2009 (UTC)

ISFDB:Serial Cleanup has been created, have at it! :-) Ahasuerus 05:23, 9 August 2009 (UTC)

Just to make sure I get this straight: Frankenstein Unbound (Part 1 of 2) by Brian Aldiss should be linked to the novel Frankenstein Unbound by Brian W. Aldiss. Frankenstein Unbound (Part 1 of 2) by Brian W. Aldiss should then be deleted?--swfritter 15:49, 9 August 2009 (UTC)

And The Sixth Glacier needs no further processing - it should be marked as fixed?--swfritter 15:56, 9 August 2009 (UTC)

That's the idea! I have added a brief explanation to ISFDB:Serial Cleanup along similar lines -- hopefully it makes sense. Ahasuerus 17:47, 9 August 2009 (UTC)

Had already read that but wanted to make absolutely sure. Thanks.--swfritter 19:44, 9 August 2009 (UTC)

(unindent) I just noticed a problem, I'm not sure if it is connected with this change or not, but it does involve VT displays. In this pub of Adventures in Time and Space, the stories "The Proud Robot" and "Time Locker" do not display their series info ("Gallegher" ). Moreover the Gallegher series is confused, with The Proud Robot (1943) [SF] by Henry Kuttner listed with variants as by Padgett and as by Kuttner & Moore under it, but with The Proud Robot (1943) [SF] by Henry Kuttner and C. L. Moore listed separately. The same is true with other author-variant works in this series, and i presume elsewhere. -DES ^Talk 23:05, 9 August 2009 (UTC)

The Adventures in Time and Space situation has to do with a VT not displaying its parent Title's series in Publications. We already have Feature Request 2813393 to change this behavior.

The Gallegher issue, on the other hand, appears to be a new bug. I can't recreate it in other series, so it may be limited to series where a collaborative title has appeared both pseudonymously and collaborative or some such. I'll file a bug report and ask Marty, our pseudonym meister, to take a look at it. Good job, Detective Inspector Siegel! :-) Ahasuerus 00:44, 10 August 2009 (UTC)

I have a feeling what I did for variant authorship isn't quite right. I will look into it when I get a chance. --MartyD 02:35, 10 August 2009 (UTC)

I take back what I said. The "variant authorship" change I was thinking of had to do with serials and did not affect other variants. What's happening in the Gallegher series display is the Kuttner + Moore variant of The Proud Robot is directly in the series, and its parent is also. So it is displayed top-level as a series member, but then it is also displayed as a variant of its series-member parent. To "fix", remove the variant from the series. Perhaps we want some specialized treatment of this case, but my understanding is that variants shouldn't be put into series directly. --MartyD 11:09, 10 August 2009 (UTC)

<nods vigorously> Good news, thanks for looking into it! Ahasuerus 13:19, 10 August 2009 (UTC)

I suspect putting such titles directly into the series was a hack to display the series in pubs, pending the implementation of Feature Request 2813393. Thanks for looking into the matter. -DES ^Talk 14:52, 10 August 2009 (UTC)

The series has been fixed and the bug has been closed. On a more elevated plane, making sure that VTs do not belong to Series will take some juggling, but I expect we'll get there in a few months. I'll try to add the fix for the Publication display issue to the next patch. Ahasuerus 15:35, 10 August 2009 (UTC)

Bug in cover art attribution code

This pub (of Nightmares and Geezenstacks) shows no art credit on the pub page: the cover URL is "http://bookscans.fatcow.com/Publishers/bantam/images/BantamJ2296.jpg". I presume that this is because of the recent domain change of the bookscans site. -DES ^Talk 14:51, 9 August 2009 (UTC)

Bug 2834577 created. Ahasuerus 19:12, 9 August 2009 (UTC)

Possible problem with replacing images

I replaced this image with a better one, but noticed that the template that appears on the page is the old one, not the new one, in which I added the artist. (Look at the file history.) Before I delete the old version and update the page again with the C3 template, can anyone who's familiar with image templates (DES perhaps) take a look at this and see if it's something I did or is this inherent in the replacement process. I thought that the template I added on the new version would automatically become the template associated with this image. Thanks. MHHutchins 20:51, 9 August 2009 (UTC)

After considerable search through the mediawiki help files I found this section where it says:

"If you are uploading the first version of a file (there is not already a file with the title you selected), then your upload summary will also be copied to the image description page. It is common in this case to provide complete information in the summary, as detailed under #Good file descriptions above." (emphasis added -DES)

I take this to mean that the upload comment is only copied to the wiki image description page when the image doesn't exist, and that when uploading an improved or revised version of an image, one must separately edit the description page if the description is to change. On thinking it over, this makes sense -- it allows the upload comment to be something like "changed brightness and cropped for improved appearance" that describes the reason for the re-upload, without replacing the description when the description hasn't really changed. I think this is just how the wiki software works, for good or bad. -DES ^Talk 22:12, 9 August 2009 (UTC)

I've now documented this in Help:How to upload images to the ISFDB wiki#Re-uploading. -DES ^Talk 23:11, 9 August 2009 (UTC)

So what you're saying is, one shouldn't bother with a description upon uploading a new version of the image, because it's not going to overwrite the original description. You will have to wait until the image is accepted and then go back and edit the original description. I really don't see the purpose of this, unless you plan to keep the old description and then add the new description. In this case, I have to remove the old description which was the C2 template. If not, there will then be two fair use templates on the image wiki page. Seems like double work, but if that's the way it's set up, there's nothing to do but do two edits each time you replace one image. MHHutchins 03:26, 10 August 2009 (UTC)

BTW, I had a new editor e-mail me with a concern that uploading images here was so much more complicated than uploading to Amazon (where he's uploaded many cover imagaes), and that he had trouble with the directions provided. I suppose we're all used to it, but I didn't realize how involved it was until I explained to him in as simple step-by-step process as I could. It was only then that I saw that it's not that simple. I've yet to see an image that he's uploaded. MHHutchins 03:31, 10 August 2009 (UTC)

What you fill in when uploading a replacement will serve as an edit summery for the upload, but that's all -- It will go into the uplaod log, adn show on recent changes -- but it will not replace the permanent description, and so should not include a license template. Of course, if the previous template was correct and complete, and the re-upload is just to have a better scan or something, no change to the wiki page is needed. -DES ^Talk 14:46, 10 August 2009 (UTC)

I think the assumption by the people who wrote the wiki software was that in the case of a re-upload, the original description would, more often than not, still apply, and no change would be needed. I could wish that they had documented this better. -DES ^Talk 14:46, 10 August 2009 (UTC)

You're right. In some cases, I didn't have to change the template, but with the new C3 template, I wanted to improve on the last version by changing it so that artists could be credited. Otherwise, I left them alone. I suppose when the new templates become more commonly used, there should be no problem in replacing images with better ones. MHHutchins 17:17, 10 August 2009 (UTC)

I am sorry that our upload process seems complex to new users. It is significantly simpler than the process at Wikipedia, if more complex than the one at Amazon. I don't see very much we could do to simplify it. If you have suggestions for how we could make it easier, please do make them.

What aspects of the directions did the user find confusing or hard to understand? Perhaps we can at least improve the directions, if not the process? -DES ^Talk 14:46, 10 August 2009 (UTC)

I don't remember him being specific as to the reasons except for the number of steps involved: naming the file (the pub tag has become the default file name, but who would know that unless they've examined the file list?), adding a fair-use template, and then updating the database record. I think that was probably the hardest part to justify, that the images are uploaded to the wiki and not to the database, and that it requires an additional step in linking the image to the pub record. I think Amazon may have spoiled some uploaders for the ease involved, but we've all encountered many Amazon images that are linked to the wrong pubs. Although not perfect, our system lessens the chance that such mistakes would occur. Imagine an Add Cover Image submit button on an imageless pub record. That would be ideal, but only if it were moderator controlled.

As for improving the directions, I'll look over them again, but if I recall correctly, they seem to be a rather straight-forward step-by-step process. I think the number of steps can be daunting to some uploaders. There's nothing we can do about that. MHHutchins 17:17, 10 August 2009 (UTC)

Well there was an attempt to make everything explicit, and each step small. Steps 1 & 2 could be combined. Step 3 could be ommitted. Steps 10 & 11 could be combined. But I'm not sure any of this would improve things. -DES ^Talk 17:31, 10 August 2009 (UTC)

BTW step 6 does say "If the image is the cover of a publication, the publication tag may be appropriate." about the file name. -DES ^Talk 17:31, 10 August 2009 (UTC)

"Add Cover Image" Button

this thread was split off from the thread above -DES ^Talk 16:31, 12 August 2009 (UTC)

Imagine an Add Cover Image submit button on an imageless pub record. That would be ideal, but only if it were moderator controlled. MHHutchins 17:17, 10 August 2009 (UTC)

Would adding an Add Cover Image button to image-less pubs that will take you to some relevant Wiki page be useful? Ahasuerus 20:56, 11 August 2009 (UTC)

The problem is what page. Logically it ought to take a user to Special:Upload. That does at least link to Category:Image License Tags and Help:How to upload images to the ISFDB wiki, and if a user actually reads and follows the directions, that should be enough. We would need to watch recent changes for images uploaded by newcomers a bit more closely, perhaps. Have a look at ISFDB:Moderator noticeboard‎#Coverart for Non-Genre magazines for a case where an upload shouldn't have passed unchallenged, and a URL assignment shouldn't have been approved. Or we could link to Help:How to upload images to the ISFDB wiki, which does in turn link to Special:Upload. That increases the chance that would-be uploaders will read the directions, but is not quite as user-friendly. -DES ^Talk 21:11, 11 August 2009 (UTC)

Well, what about a new Wiki page with a few words of welcome and pointers to the Help and Special:Upload pages then? Ahasuerus 21:33, 11 August 2009 (UTC)

Frankly IMO that would be the worst of both worlds. Since it isn't the upload page itself, you have to click-through to a different page, so it doesn't feel as user-friendly as a direct link to the upload page would. And since it isn't the actual help page, users who don't tend to follow links to directions won't see the help. I think we should either link directly to the upload page, and trust most users to read the help linked there, or else link directly to the help, so that users are at least exposed to it, and must link through to the upload page. Once we have a User preferences page, we could by default link to the help, but allow users to link to the upload page directly via a preferences setting. Of course, others may disagree with me on the matter. -DES ^Talk 22:06, 11 August 2009 (UTC)

[unindent] Just brainstorming here: is it possible that clicking on the button will transfer the tag of the pub into the filename field of the upload page? MHHutchins 22:20, 11 August 2009 (UTC)

I don't think the software supports that, and even if it did, when the user picks the file name on the local computer, that overrides the destination name. -DES ^Talk 22:57, 11 August 2009 (UTC)

Just a note that it would be a minor change to add a link from the Pub screen to a Wiki page, so if adding it would make life easier for the editors who upload a lot of images, we could easily do it. Ahasuerus 04:15, 12 August 2009 (UTC)

That might be a good idea. In fact i think it would. But can we add a link that pre-fills the filename field, as MHHutchins suggests? If the answer is yes I'll be pleasantly surprised. -DES ^Talk 04:24, 12 August 2009 (UTC)

Not that I know of, but we could ask Marty, who has experience with the MediaWiki software. Ahasuerus 13:13, 12 August 2009 (UTC)

https://isfdb.org/wiki/index.php?title=Special:Upload&wpDestFile=TestMe.jpg&wpUploadDescription=This+is+a+test will bring up the upload form with the file name and summary filled in. (I just provide both as an example; either can be omitted). Is that what you're asking? --MartyD 15:49, 12 August 2009 (UTC)

Looks great to me, but I haven't done mass image uploading. Let's see what our core audience thinks. Ahasuerus 15:53, 12 August 2009 (UTC)

I am very presently surprised indeed. And the destination file name isn't replaced when picking a source file from the local computer (as it is if you've typed in the destination yourself, IME). Great. Could the summary be a call to {{Cover Image Data}}, or perhaps {{CID3}} with the parameters filled in? Most or all of the parameters can be mechanically determined from the fields in the publication record. That would make uploading cover MUCH quicker and easier, i would think. Thank you! -DES ^Talk 16:01, 12 August 2009 (UTC)

You'd have to try it and see. I'd think that if using the template directly in the summary (i.e, typing "{{CID3|...}}" into the summary box) does what you want, then pre-populating it via the URL would also work. There might be some URL encoding challenges with the braces, but I don't image they'd be too tough. If templates don't work in the summary, I suppose the summary could at least be some text that one could copy+paste elsewhere. --MartyD 16:22, 12 August 2009 (UTC)

Templates do work in the summary, I do it that way routinely. What I was concerned with is if the template call can be constructed by the code at the time the button is pushed - in particular if data can be retrieved from the various fields and inserted into the template call, so the user no longer has to cut&paste data from the publication page to the upload page or to the wiki page. That would be the big time saver, IMO. -DES ^Talk 16:27, 12 August 2009 (UTC)

I'm going to split off this sub-thread, the name is no longer descriptive. -DES ^Talk 16:27, 12 August 2009 (UTC)

(unindent) Would there be any objection to my creating a feature request for this? -DES ^Talk 16:32, 12 August 2009 (UTC)

Sounds like a great idea! Ahasuerus 16:44, 12 August 2009 (UTC)

FR 2836579 (Add Cover Image to this Pub) created. -DES ^Talk 23:26, 12 August 2009 (UTC)

(unindent)Since I seem to upload a lot of images, DES asked me to chime in. I'm sure the Add Image Button would be great for occasional users. When I'm editing I always have the "Upload" page open in a separate tab. Once an image is ready (cropped, sharpened, etc) it's one step to choose the file. Second step to put in the destination file=pub tag.jpg (this is a straight copy paste step) then third step to do the summary. Since I always have the page open, it displays the last summary I did. To change this from a { { C } } to a { { C3 } } or whatever is one keystroke, then paste the same tag and type the artist/title. The whole process is less than 10 seconds, even with two artists. I'm not sure the Add Image Button would do much for me, regardless of what data it would pre-load. The wait to just have the page come up would not likely be less than the time to copy-paste the pub tag. What I would like to see is when the image upload is complete it would automatically be linked to the pub, as that is an extra step, though again only a copy-paste. ~Bill, --Bluesman 17:04, 12 August 2009 (UTC)

If by "it would automatically be linked to the pub" you mean the link from the wiki page to the db pub page, then the pre-fill planned here would do that automatically. If you mean adding the URL into the proper field of the pub editor to make the link from the pub record to the image, than I'm not sure if this will do that automatically or not -- i suspect not. -DES ^Talk 20:51, 12 August 2009 (UTC)

Sorry, linked was incorrectly used. I mean that the image URL would be inserted into the pub field as soon as it's uploaded, rather than have to copy/paste it there. ~Bill, --Bluesman 22:10, 12 August 2009 (UTC)

I see, that makes sense. I'm not sure if that will be possible or not -- I agree it would be nice if it could be done. -DES ^Talk 23:26, 12 August 2009 (UTC)

A way to do this is the pub-display logic for looks for "Image:pubkey.jpg‎" and if present it then it looks up the image URL. --Marc Kupper|talk 22:09, 15 August 2009 (UTC)

Database freeze

The database froze up around 11:30am EDT this morning due to what appears to be a bad query in the Advanced Search. I captured the query, which will be analyzed later, and bounced the database. We should be back to normal. Ahasuerus 15:40, 12 August 2009 (UTC)

Overwriting existing variants

Working on the serial cleanup project, I have noticed that the "Make this title a variant" link brings up the MakeVarient page, but that page doesn't in any way indicate whether the title is already a variant. Often, of course, using "Make variant" on an existing variant is done intentionally, to break or re-point a variant relationship. But sometimes it is a mistake. Does anyone else think it would be a good idea to indicate that the title is already a variant, perhaps by pre-filling the parent record number? -DES ^Talk 16:41, 12 August 2009 (UTC)

That's a good point -- more pertinent information is always good to have. Going forward, we may also want to add an explicit "Break this VT relationship" option or button since the "0" method was a short term workaround. Ahasuerus 16:58, 12 August 2009 (UTC)

Patch r2009-17 is live; new bug introduced

Patch r2009-17 has been installed on the live server. The following changes have been made:

• Bug 2834027. 62 defunct pseudonyms have been deleted. They were causing empty "Used As Alternate Name By:" lines and similar issues. Defunct pseudonyms are created when we merge Author records which have associated pseudonyms; the merge bug has been identified and recorded but hasn't been fixed yet, so it's possible that more defunct pseudonyms will be created before we get a chance to fix the Author merge behavior.
• Bug 2833255. When an editor tries to enter a Publication with no Author, the system no longer tells him to use "Anonymous" when there is no author present. Instead it displays a message explaining the use of "uncredited", "unknown" and "Anonymous" as per Help.
• Bug 2834577. Cover art provided by Bookscans is once again properly credited. They moved to a new site recently, so we had to update our software to make it recognize the new location.
• Bug 2834596. Variant Titles now appear as "Forthcoming" if they are scheduled to be released in the future.
• Bug 2817694. Chapterbook Publications now link to Chapterbook Titles rather than to the first Shortfiction Title in the Publication.
• Bug 1885545. The script that moderators use to view the raw XML submission text no longer errors out if the submission number doesn't exist.
• Feature Request 2836479. The message which tells the submitter that he should check his Talk page is no longer displayed if the submitter has edited the Wiki more than 100 times.
• Bug 2753972. Linking to a publication whose Tag consists exclusively of digits now works, but it introduced another bug which prevents linking to Pubs by ID. This will be fixed shortly. The change to allow numeric Tags caused other problems and has been reverted. Since we don't have all-numeric Tags in the database at the moment, we can prevent their creation in the future and not have to worry about this.

Please post any other issues that you may run into here. Ahasuerus 04:16, 16 August 2009 (UTC)

On Bug 2833255: the revised warning is nice. However, if an editor entering a pub with content items omits the author for one such item, the resulting msg is: "*** ERROR: Entry must have an author. Title=<Item title>". it would be nice if this msg also included the note about "uncredited", "unknown", and "Anonymous". (it would be even nicer if there was a graceful recovery for those whose browsers don't cache field-level data and restore it wioth the back button.) -DES ^Talk 17:01, 17 August 2009 (UTC)

Sounds reasonable -- FR 2839257 created. Ahasuerus 21:47, 17 August 2009 (UTC)

Isbn-13 with 294 prefix

Just as an experiment I entered one of the Barnes & Noble Books / Google Books titles. The real ISBN is in the notes. I am not even sure that the ISBN is truly valid since it is not stored with the ebook. Also there is little effort to proofread the books as Project Gutenberg does and OCR translations are sometimes a little flawed. Also no release date. I won't be entering any more but others may and there does not seem to be sufficent justification for excluding them. I am waiting to see how fictionwise is going to handle these same books.--swfritter 15:48, 16 August 2009 (UTC)

Updating of the serial help page

Working with a submission that wanted to merge the records of two serializations of one title, I searched the help pages for the documentation to show that this is not the current practice on the ISFDB. After five-ten minutes of fruitless searching (I never have been very good at finding what I need with the Wiki search), I came upon this page. Considering that the SERIAL type is in the process of being significantly revised, it appears that the updating of this page is more relevant than ever. At the moment it has a warning that it's still in progress, which is fine by me, but some consensus has to be arrived at once the revised SERIAL type has been completely implemented. MHHutchins 04:54, 17 August 2009 (UTC)

Search for "complete novel" on this page. The page you list above was I think designed less to be a statement of basic policy than an explanation of the logic behind it although there are a number of arguable points. And it is only a rough draft. Technically the policy now only applies to serials reprinted in magazines but as with Zelazny we are starting to see them reprinted in books and Project Gutenberg titles with the same text as the original source. We may need to address that issue but the changes to serial processing are primarily technical and it seems to me would not of themselves require any change of basic policies.--swfritter 14:10, 17 August 2009 (UTC)

Now that the Serial rework is in progress, we may want to change Help to indicate that Serial Titles need to be made into VTs of their parent Novel/Shortfiction Titles (if they exist). Ahasuerus 21:55, 17 August 2009 (UTC)

Bug in entering contents of omnibus and nonfiction

I was entering an omnibus containing three novels and a novelette, and was unable to enter the novelette as SHORTFICTION. The choice wasn't on the dropdown menu. I had to enter it as POEM, then go back later and edit the title record after the submission was accepted. Also found while experimenting that I couldn't had a shortfiction to a nonfiction record. That's rare, I admit, but it happens. This must have happened in the recent round of software changes, as I've added shortfiction quite often to both record types. MHHutchins 16:53, 17 August 2009 (UTC)

You're right, when we[1] stopped making SHORTFICTION the default for contents of every type of new publication, we accidentally made it completely unavailable for contents in the title types where the default changed. Easy one-line fix though - I think. But as it got past testing as well we ought to consider what tests we should have done. BLongley 19:55, 17 August 2009 (UTC)

[1] Yes, it's me, but when I cock-up I like to share the blame with the tester(s), the implementer and possibly the requirements analyst(s). ;-) BLongley 19:55, 17 August 2009 (UTC)

Fix committed, but it really should be tested a bit better this time. Particularly as I don't seem to recall which month it is now - it's a month and 16 days ago that this was introduced. Treat all my submissions as a bit suspect at the moment, I'm not at my peak. BLongley 20:11, 17 August 2009 (UTC)

Yup, the tester most certainly missed it -- I'll have a talk with him tonight. Hopefully he will do a better job next time! Ahasuerus 21:48, 17 August 2009 (UTC)

Flier for First Fantastic Fiction Bibliography for sale on eBay - Bleiler 1948 Checklist

The item SHASTA PRESS: BLEILER. CHECKLIST FANTASTIC LIT. PROMO is item # 290338879325 on eBay. Someone else has bid more than I wanted to pay, but I thought you other bibliophiles might be interested. - Cheers - Kevin 23:27, 17 August 2009 (UTC)

Adding Pubs to Titles - possible Feature Request

Based on a recent discussion over on Help Desk, we may want to consider improving the way we "Add Publication" to a Title. At the moment, this option adds a new Pub to the currently displayed Title, which is straightforward in most cases. However, if the currently displayed Title is a Variant Title or has Variant Titles associated with it, then it's not always clear which Title you are adding your Pub to. How about this Feature Request:

When an editor selects "Add Publication to This Title" for a Title that is either a VT or has VTs associated with it, the system should present the editor with a list of Titles which will include the canonical Title and all the VTs. For each Title, the system will display the author, title, title type, year of publication and storylen. The editor will then be able to select one (and only) one Title via a radio button and proceed to the current "Add Publication" page.

? Ahasuerus 17:45, 18 August 2009 (UTC)

That sounds like an extra module between the "Add Publication to This Title" link and the actual "Add Pub" screen, and I don't think anybody's added any new screens yet, and such probably leads to adjustments to "make" functionality etc. BLongley 18:27, 18 August 2009 (UTC)

Marty added a new Python module for FR 2805588, which included changes to 4 "mk" files and to "Makefile" in "common", so I think the trail has been blazed :) Ahasuerus 18:40, 18 August 2009 (UTC)

A simpler fix for now might be just to make pre-populated Authors non-editable on the Add Pub screen (like contents aren't editable on "Clone Pub"). BLongley 18:27, 18 August 2009 (UTC)

It would certainly be an improvement since it would guarantee a consistent submission with the Publication level author matching the Title level author, so we may want to do it first. Ahasuerus 18:40, 18 August 2009 (UTC)

But there are other related issues, like currently being able to Add Pub to Content title types like REVIEW. BLongley 18:27, 18 August 2009 (UTC)

Hm, I don't think we have a Bug report filed for this issue, do we? Ahasuerus 18:40, 18 August 2009 (UTC)

I'm not sure of the extent of it. I think people used to use that loophole with SHORTFICTION to create CHAPTERBOOK entries? BLongley 18:45, 18 August 2009 (UTC)

Yet another reason to close it now that we have CHAPTERBOOKs mostly working! :) Ahasuerus 18:59, 18 August 2009 (UTC)

2 more Feature Requests

While I am thinking about it, how about the following FRs:

1. Add a new "Change everywhere" checkbox to each line of the Contents section in the Edit Publication screen. When checked, Title level changes to the data will be applied to the existing Title, which is what happens now. However, if the checkbox is not checked, then a new Title with the entered data will be created instead, which should help prevent problems with changes to unrelated pubs affecting other editors' verified pubs. The Moderator screen will need to be adjusted accordingly.

2. After submitting a new Pub, the submitting editor will be given a list of all newly entered Titles whose author and title match currently existing Titles. For each Title, the editor will then be able to select the date, storylen and series data. The moderator screen may require minor changes, but it already has support for the "Auto Merge" functionality.

I believe we have discussed both ideas over the last year or two, but I don't think we have finalized the details, much less documented them as Feature Requests.

P.S. The development process is a little sluggish at the moment due to vacations, work, illness, etc. I don't know when we may be able to get this done, but it's better to have the desired functionality documented before we forget the details again. Ahasuerus 18:14, 18 August 2009 (UTC)

I'm not sure what you mean by 2. A list of the newly entered titles would be useful if it was for merging purposes, but the titles to be merged aren't created at that point. Why would you want to look at similar titles to the new ones at that point in time? BLongley 18:39, 18 August 2009 (UTC)

Perhaps I wasn't quite clear on the intent, so let me take a step back. One of the problems that we currently have is that if you are entering a new collection of, say, Poe stories, you have to wait for the submission to be approved and then go back and merge the newly entered stories with their pre-existing counterparts. That's tedious, to say the least. A much better way to handle the issue would be to let the submitting editor identify the Titles that he will end up merging the new data with up front.

Now, ideally, the whole thing would be done via this new-fangled Web 2.0/AJAX technology, which lets sites like Google provide you with a list of partial matches as you type in your query. In our case, as Al once suggested, it would mean that as soon as the user types "The Moon Is", he gets a drop-down list with "The Moon is a Harsh Mistress", "The Moon is a Harsh Spaceship: A Review of Space: 1999", "The Moon is a Sexy Geisha", The Moon Is Death", etc complete with authors, years and title types so that he could pick the one he wanted. Unfortunately, I don't think we have the expertise to implement something this major and, besides, there would be some technical issues involved. For example, there are authors who have re-used titles (talk about cheap!) and you really need to read the Notes field to decide which title you want your newly entered story to be merged with, which can be hard to fit in a drop-down list.

A simpler -- although not quite as elegant -- solution would be to have the editors go through the data entry motions, hit "Submit" and then have an opportunity to identify which newly entered Titles need to be auto-merge with currently existing Titles. Displaying all Notes for each auto-merge candidate may make the screen look a little busy, but better safe than sorry! Ahasuerus 19:22, 18 August 2009 (UTC)

Going to all that trouble makes me think something like a singleton "Import Title" button, right in the Add Contents area would be useful. I've wanted that many times. --MartyD 21:02, 18 August 2009 (UTC)

Functionally, "Import Title" is exactly what I was trying to accomplish, the rest is just "implementation details" :) The question, though, is how would this button work? I suppose we could add a new Contents level field for "Title number", but how would a button work? Ahasuerus 21:31, 18 August 2009 (UTC)

I haven't put much thought into it, but mechanically I suppose it would be similar to Import Contents, but would work one title at a time, in place. So it would bring up some kind of search-like interface, allow locating and choosing a title, and then load a mostly read-only content entry similar to those entries provided by Import Contents, where one can supply a page number but that's about it. No transient title, no need to merge. --MartyD 21:40, 18 August 2009 (UTC)

Ah, I see. I think it would be a more user-friendly solution than what I had in mind. For starters, it would make it easier to find titles (no need to enter them exactly) and it would import the whole record, including the publication date and storylen, so the likelihood of an error would be further reduced. However, I am not sure how we could implement something like that. A pop-up window, perhaps? We already require Javascript for editing (but not for browsing), so that shouldn't be an issue. Ahasuerus 21:52, 18 August 2009 (UTC)

Why make the transient title in the first place? --MartyD 21:02, 18 August 2009 (UTC)

It was the only way I could think of that would eliminate the need to merge Titles after the fact. If there is a better way, hey, so much the better! :) Perhaps I was too focused on the way "Check for Duplicates" -- which uses a similar two step solution -- works. Ahasuerus 21:31, 18 August 2009 (UTC)

(I think this may need to be split - 1 looks fairly agreeable, 2 is unclear.) Even without AJAX, we could probably add a "Replace this title with a known variant" button (yes, it would need a snappier name) against each content title so that an editor doesn't have to do the "Add Title", "Remove Title", "Merge Titles" shuffle. But maybe that does overlap with 1 - as in "that's not exactly the way it was credited, but we don't have my version on record yet, so I want to add this as a variant content title in one step". The page would get larger as we add all sorts of extra options like this, but it's possible. I have no idea what the performance would be like if we enabled this and somebody wanted to add "The Complete Robert Heinlein" by copying "The Complete Robert A. Heinlein" (all those variants of "And He Built a Crooked House" for instance), but it's possible. BLongley 21:57, 18 August 2009 (UTC)

Marty might have hit the happy medium - do it on a content record basis, and grab the alternative content records if somebody wants to adjust a single record, for an automerge on approval - but unless we add that as standard we'll run the overhead of checking whether there IS an alternative record for each title in advance, which could be slow. Still, interesting ideas here. BLongley 21:57, 18 August 2009 (UTC)

(After edit conflict): As to adding new (to this pub) but existing (elsewhere) contents, then an "Import Content Title" would be good, but how to guess what you're trying to import? "Another title by this author" could be a very long list. Adding something to an Anthology would be a VERY long list. A variant title of an existing entry is simplest (see above) and is what I would use most (and what I have to explain to new editors most, it seems). BLongley 22:09, 18 August 2009 (UTC)

I would think that that "Import Content Title" would need to pop-up or go to a search page, whether the editor could search on title or author (or perhaps both), and ultimately check or click on a single selected title. This would then return to the main form with the itme imported. I'm not sure how hard that would be to implement, but i think it would be the ideal interface. -DES ^Talk 22:21, 18 August 2009 (UTC)

ISFDB images without www not credited

If an image hosed by the ISFDB, such as the one on Siege at Gazbriz has an image URL that omits the "www", such as http://isfdb.org/wiki/images/d/d3/9781907287008.jpg (rather than http://www.isfdb.org/wiki/images/d/d3/9781907287008.jpg) then the "Hosted by ISFDB" link is not displayed. See Bug #2841352. -DES ^Talk 19:45, 20 August 2009 (UTC)

New bug with suffixes

Just a heads up that we found a new bug less than an hour ago. If you have two (or more spaces) between the author's name and the suffix, e.g.:

Charles E. Sellier,  Jr.

as opposed to:

Charles E. Sellier, Jr.

the software will error out in a particularly messy way. I just spent 40 minutes cleaning up the database and it wasn't pretty, but everything seems back to normal now. We expect to fix the bug in the next 7-14 days, but for now please make sure that you don't have extra spaces before suffixes. TIA! Ahasuerus 19:41, 23 August 2009 (UTC)

Another ebook publisher

From a new submisison by a new editor (submitting a record for his own book) I found "Writers Exchange E-Publishing", aka Readers Eden. They appear to have something over 200 ebooks that are probably speculative fiction (in their categories "Science Fiction", "Fantasy/Paranormal Fantasy" "Paranormal", "Time Travel", "Vampire", and "Werewolf, The Hunt and other fantastical or mythological creatures"). These ebooks are downloadable, published in multiple formats, and are being offered for sale (for money). They seem to fit our ebook criteria. At least some of them are aimed at a juvenile audience. -DES ^Talk 16:07, 24 August 2009 (UTC)

Books for that publisher are also available at Fictionwise.--swfritter 13:06, 25 August 2009 (UTC)

Of interest from Project Gutenberg: A Short History of EBooks.--swfritter 12:11, 26 August 2009 (UTC)

Patch r2009-18 live

Patch r2009-18 has been installed on the live server. The following changes have been implemented:

Publication display changes:

• FR 2813395 and duplicate FR 2805052 When a Variant Title is displayed in a Publication and the only difference between the VT and its parent Title is the name of the story (i.e. the Author(s) is/are the same), the author's name is no longer displayed for a second time. E.g. note how the last four titles in Planet of Doom and Other Stories no longer show their authors' names twice.
• FR 2813393 If a Title is not in a series, but its parent Title is, the Series is now displayed next to the Title in the Publication display screen. This is particularly useful now that Serials are VTs of their parent Novels. E.g. note how "Gray Lensman (Part 1 of 4)" and Campbell's "Invitation" appear in Astounding Science-Fiction, October 1939.
• FR 2813396 If the parent Title of a VT has a different date, that date is now displayed next to the parent title on the Publication Display screen. E.g. see the way "Beyond This Horizon (Part 1 of 2)" is displayed in Astounding Science-Fiction, April 1942
• Bug 2841352 ISFDB-hosted images are properly credited even when the URL starts with "isfdb.org" rather than with "www.isfdb.org"

Search changes:

• FR 2830507 When an Author record is marked "Pseudonym" yet has regular (i.e. non-variant) Titles associated with it, we now display "Has Pseud. Titles" in the "Pseudonym" column. This happens either due to ghost writers (a la V. C. Andrews) or, more commonly, because some regular Titles haven't been converted to VTs yet.
• FR 2833399 If a regular search finds more hits than it can display (usually 100, but some searches display up to 300 hits), a link to the Advanced Search page appears at the top of the Search Results page and an explanatory message is displayed. It has been added because many occasional users don't know what to do when they run into this limitation of the regular search (as per Usenet posts).

Moderator changes:

• FR 2813434 Moderators can now see a full list of Verifications, secondary as well as primary, when approving Publication Update submissions. In addition, the yellow warning is displayed not only for Primary Verifications but also for Transient and Primary2-5 verifications.

Bug Fixes

• Bug 2839351 SHORTFICTION is once again a valid drop-down choice in the Contents section of Omnibus and Non-fiction publications.
• Bug 2839253 You can once again change canonical names to their accented forms, e.g. "Agnes Dodart" to "Agnès Dodart" and back.
• Bug 2838365 If you attempt to clone a Magazine record, you will now receive a properly worded error
• Bug 2824029 The Add Publication page no longer gives you the choice to delete the Pub.

Other minor changes:

• FR 2830968 The page displayed after assigning or deleting a Tag now links back to the Title page.

Please report any problems with the patch here. (And I may need to take a couple of days off before tackling the next project, Series. This is more exhausting than one might think.) Ahasuerus 01:34, 25 August 2009 (UTC)

208.100.59.10

http://www.isfdb.org/index.html contains a short chunk of JavaScript that immediately points the browser to http://208.100.59.10/cgi-bin/index.cgi. I'm trying to remember why this is needed but can only find ISFDB:Community_Portal/Archive/Archive11#ISFDB editing disabled tonight and ISFDB:Community_Portal/Archive/Archive11#DNS Problems with 208.100.59.10. For a while this was playing havoc with the NoScript extension with multiple clicks needed to allow the jump each time I went to www.isfdb.org. Plus if you did a basic search from http://208.100.59.10/cgi-bin/index.cgi there was unhappiness as the results were at http://www.isfdb.org/cgi-bin/se.cgi.

I've since decided to disable NoScript as it slowed the browser down too much but also can't recreate the problem with 208.100.59.10. Maybe if got fixed by the NoScript update that came out yesterday. --Marc Kupper|talk 08:31, 26 August 2009 (UTC)

I had occasional display problems apparently related to the "208.100.59.10 problem" whenever I was logged in from behind a particular commercial strength firewall. Al would probably be the right person to ask about it. Ahasuerus 02:42, 28 August 2009 (UTC)

Serial cleanup update

The Serial cleanup project is proceeding apace and we are half way there. I have archived the completed sections and added a new one for "malformed Serial titles". In the meantime, I am working on a script that will automatically convert all straightforward lexical match cases to VTs. Ahasuerus 02:45, 28 August 2009 (UTC)

Another section listing Serials that match multiple Novel/Shorfiction Titles has been added. In some cases a Shortfiction piece was later expanded to novel length and we need to figure out whether the Serial record needs to be made into a variant of the original Shortfiction or of the eventual Novel record. Other times we have duplicate titles (e.g. we apparently have 3 Title for H. G. Well's The Time Machine) in which case we should merge the Novel/Shortfiction Titles before making the Serial Title into a VT. Ahasuerus 00:46, 30 August 2009 (UTC)

And finally we have a list of Serials that match Novel or Shortfiction Titles which are, in turn, variant titles of other Novel/Shortfiction titles. In most cases, these Novel/Shortfiction titles have no real publications associated with them. They were set up as placeholders so that the "lexical match" logic would work and need to be deleted once "their" Serials have been set up as VTs of the canonical Novel/Shortfiction titles. However, there are some cases where the VT Novel/Shortfiction Title has legitimate Publication records associated with it, in which case the VT needs to be preserved.

The good news is that, as far as I can tell, this is the last list of records that need to be cleaned up manually. Once we finish processing all records currently listed on ISFDB:Serial Cleanup, we should be able to run an automated conversion for all other Serials and then disable the "lexical match" logic. And there will be much rejoicing! :) Ahasuerus 01:22, 30 August 2009 (UTC)

Server hangs

We had a server hang earlier today (2009-08-29) and it had to be bounced to bring it back from the dead. The good news is that we have found what causes at least some of these hangs. When you select certain permutations of search criteria in Advanced Search, the software builds a query which goes into the never-never land and takes the server with it. We are currently working on a fix, but at least we know where the problems is. For now, we need to abstain from running "OR" Advanced Searches which use all three search terms. Thank you for your patience! Ahasuerus 21:45, 29 August 2009 (UTC)

Thanks to Marty's tireless work today, a fix has been created, tested and deployed on the live server (patch r2009-19). Advanced Title Searches should no longer cause database hangs, although some types of searches, e.g. "Title = Life OR Author = Asimov", may still take up to 10+ seconds just like they did before. Thank you, Marty! :) Ahasuerus 01:41, 31 August 2009 (UTC)