Talk:ISFDB Feature List

Features needed for beta

Al currently has the pseudonym editor and watchlisting ISFDB data on the feature list for pre-beta. My own list would not include the pseudonym editor, which I think would be handy but not necessary. I'd ask for:

• watchlisting titles
• resubmit rejected records

and possibly

• free text deletion reason field for deletetitle, delete pub
• free text rejection reason field for rejected submissions

An issue occurred to me regarding multiple submissions that would have an impact on resubmitting rejects too. Suppose you have an UpdateTitle submitted by editor A, and later, but before the UpdateTitle is approved, a MergeTitle submitted for the same title by editor B. Now suppose a moderator approves the MergeTitle first. The UpdateTitle is now going to try to update a record that no longer exists.

Rejected records might become "out of sync" in the same way. I don't think this is a showstopper, though; it's going to be relatively rare, I would think, and I can't offhand see a way it would cause data corruption, although I need to think about that some more. Including verification that relevant data had not changed since submission would be quite difficult -- I've written code like that and it's non-trivial. Mike Christie 04:48, 29 Nov 2006 (CST)

Not that I am necessarily advocating implementing something like that pre-beta, but would adding a "last edited" timestamp to all records and to all submissions (to be compared at approval time) help alleviate the problem? Ahasuerus 09:41, 29 Nov 2006 (CST)

A follow-up comment. Though I think there are lots of very useful features that would help, I think Ahasuerus is right that we don't yet know enough about how editors will really operate to assert that we have to have the watchlist and resubmit capabilities. I'd be willing to go along with just getting the bugfixes done and starting the beta. The risk, as Ahasuerus pointed out somewhere, is that we discourage editors who don't then return. I think good support from the moderators can ameliorate that risk.

If I get just one feature, I think it's resubmit rejects. That would cut down on frustration more than watchlisting would. If I get two features, it would be linking "recent edits" to the moderator display, for all editors, so anyone can see what was changed. That would be a crude watchlist. Mike Christie 05:02, 29 Nov 2006 (CST)

Numbering

Any objection to me numbering the features? I'd start at 90001. I think I'd lose the "Series" separator; I don't think there's a need to track those independently, is there? Mike Christie 07:26, 2 Dec 2006 (CST)

Sounds good! Ahasuerus 17:37, 2 Dec 2006 (CST)

For features, should we make the feature numbers wiki links, to say Feature:90023? Many of these features (title charactirization, for instance) will need some amount of requirements gathering on how the feature should look, work, or be documented. It would be nice to collect that information in a single location, and it's a bit awkward to put all of that in the global feature list. Alvonruff 04:56, 15 Dec 2006 (CST)

Title characterization

I'm picking up a thread from Bibliographic_Rules#How_do_you_record_split_publications? which was getting rather long, and also because what I want to suggest is nothing to do with the current biblio rules.

It seems that a lot of what we want to say about a title is a way to characterize it -- it's abridged, fixedup, rewritten, expanded, translated, part 1 of a serial, 1965 edition, and so on. Would it be useful to add a "Characterization" field to the title record which would allow these options? Actually it could be free text, though I'd think we'd want to limit the variations somewhat. Then you could have title="Jem", characterization="", distinct from title="Jem", characterization="Part 1 of 4". Mike Christie (talk) 22:47, 14 Dec 2006 (CST)

What you are describing sounds similar to what I mentioned over on Bibliographic Rules the other day with two exceptions. First, I was thinking more along the lines of a dropdown list of allowed "characterization", but free text may well be a better way to go. Second, I was thinking that this "Characterization" field would apply to Variant Titles only and would be more of a "Relationship [to the parent title]" field. You seem to be suggesting that this field could be populated for any title, including standalone titles. How do you envision it being used for parent titles? Cases like "cut by publisher" so that subsequent Variant Title information, e.g. "text restored", would make more sense when displayed? Ahasuerus 00:02, 15 Dec 2006 (CST)

My 2-cents says I’m fine with a characterization field. In my own book list I thought about such a field but then realized I was adding notes all over the place (titles, sub-titles, author names, publisher names, etc.) and so I instead went with allowing (notes in parentheses) and the logic truncates those off as needed. Al may already be truncating at the "(" as the code already deals with “(part 1 of 3)” serialized titles. Marc Kupper 02:56, 15 Dec 2006 (CST)

Titles would be grouped and characterizations would be grouped and/or sorted. Translations could have the pubtitle in the actual pub language, the title title in the canonical version language, and a characterization on the title of "translation". Then they'd list under the canonical title if we want, or could be grouped separately as translations (ultimately a preferences checkbox). Mike Christie (talk) 22:47, 14 Dec 2006 (CST)

That would be certainly ideal, but first we would need to add some form of language support and populate the language field for some [unknown] thousands of records. That will take a while :-\ Ahasuerus 00:02, 15 Dec 2006 (CST)

Abridged, fixup, rewritten -- these are just displayed as parentheses after the title, but aren't part of the links, so the length of the hyperlink would be the only difference between this display and the approach of incorporating the parenthetical characterizations into the title field. Mike Christie (talk) 22:47, 14 Dec 2006 (CST)

We would be effectively replicating the standard encyclopedic functionality whereby titles are printed in one font (e.g. italics) and any additional information like "abridged" is printed in a different font. Which sounds eminently reasonable. Ahasuerus 00:02, 15 Dec 2006 (CST)

That gave me an idea for the DAW list and it was less then five minute’s work to fix the hyperlink generator for links to end the link before the " (". Marc Kupper 02:56, 15 Dec 2006 (CST)

Prioritizing features

Here's my list of features that I'd most like to see; I thought it would be useful to Al to get everyone's input on what would be most beneficial. I haven't paid attention to whether a given feature is easy or hard to implement, just to desirability. These are in order, with the most desirable (in my opinion) at the top. Any other opinions?

1. 90044 Historical display of edit contents
2. 90050 Query to find edits relating to a title or pub
3. 90075 Pseudonym and vt sourcing
4. 90063 Support for chapterbooks in bibliography displays
5. 90047 Unmerge selection checkbox to unmerge individual pubs
6. 90034 Separate "non-fiction" flag from "publication type" flag
7. 90065 Colour-code links to wiki to show if they have contents
8. 90067 Add Help link to wiki from ISFDB
9. 90072 Sort contents records in editpub display
10. 90074 Interior art display
11. 90037 Resubmit capability for rejected edits
12. 90017 Free text reason field for merge/delete edits

-- Mike Christie (talk) 08:49, 27 Dec 2006 (CST)