ISFDB talk:Beta

diazepam online order tramadol wellbutrin online jazz ringtones cheap rivotril free mtv ringtones cheap lipitor celexa online ativan online free nokia ringtones norco online motorola ringtones ultram cheap ultram norco free mono ringtones celexa online buy didrex free online pharmacy cheap propecia phentermine online viagra online cheap vicodin cheap sildenafil lisinopril online sharp ringtones online levitra funny ringtones but hydrocodone online valium free cool ringtones cheap clonazepam cyclobenzaprine online verizon ringtones buy hgh ambien online sony ringtones cheap cialis free cingular ringtones cheap cialis prozac online qwest ringtones cheap didrex punk ringtones jazz ringtones free ringtones ultracet order flexeril free nokia ringtones cheap ativan cheap viagra free midi ringtones free sony ericsson ringtones real ringtones adipex online free funny ringtones free punk ringtones cheap tenuate meridia free kyocera ringtones free sprint ringtones meridia tenuate online clomid online ambien online sonyericsson ringtones cheap clomid free music ringtones ericsson ringtones cheap levitra wwe ringtones kyocera ringtones cheap nexium free mp3 ringtones cheap hgh cheap xanax free sagem ringtones xenical online alprazolam free music ringtones buy zanaflex free verizon ringtones free nextel ringtones tracfone ringtones diethylpropion online albuterol online buy tramadol samsung ringtones free mp3 ringtones free wwe ringtones soma online sharp ringtones lisinopril online paxil online motorola ringtones samsung ringtones vigrx sildenafil online paxil online cheap zanaflex rivotril online diethylpropion online free sprint ringtones free polyphonic ringtones free sagem ringtones cheap nexium free cingular ringtones cheap cyclobenzaprine pharmacy online online free alltel ringtones free sonyericsson ringtones sony ericsson ringtones diazepam online vicodin lipitor online cheap vigrx free mtv ringtones cheap soma lorazepam online free real ringtones cheap zyban albuterol online ericsson ringtones lorazepam online zoloft adipex wellbutrin online alltel ringtones free cool ringtones nextel ringtones zoloft online cheap clonazepam valium online order fioricet midi ringtones xanax online polyphonic ringtones hoodia online lortab cheap alprazolam cheap hydrocodone lortab online cheap ultracet free free ringtones mono ringtones carisoprodol online sony ringtones ortho online tracfone ringtones phentermine cheap ortho xenical online prozac online carisoprodol online propecia online but flexeril free qwest ringtones fioricet online cheap hoodia zyban online

Enable editing for beta testers

Al, can we enable editing for beta testers without enabling it for all non-moderators? Mike Christie 17:31, 28 Nov 2006 (CST)

I don't know for sure, but I don't think so. Also, it looks like Al is being held hostage by the Work Monster again :( Ahasuerus 13:00, 4 Dec 2006 (CST)

Al got held hostage by the Winter Storm Monster. No electricity for two days, Internet back this morning after four days. Enabling editing for beta testers would require creating a temporary table of user ids allowed to edit, along with some tools to edit that table (the MediaWiki table we use for users only has two kinds of users, not three). What's the downside of opening things up for everyone? I'm not convinced that there are hordes waiting for editing to go online - even us moderators don't edit that much ourselves (we've been averaging about 130 edits per day between us for the last 2 months). I can go either way - but there will be some additional work to get a third partitioning of the users going. Alvonruff 13:55, 4 Dec 2006 (CST)

Then let's not bother. If it becomes a problem we can shut down user editing; seems unlikely. And as you say there are probably not hordes of users waiting for beta. That doesn't mean there isn't a beta period, though; I think it's still worth having a beta with entry and exit criteria -- partly so that users realize, at least, that there may be teething problems. Mike Christie 14:02, 4 Dec 2006 (CST)

ISFDB data is frequently cited by quite a few rec.arts.sf.written posters, so it's possible that we will have a few dozen somewhat active editors if we simply post a "Hey, we are open for beta testing, please be gentle and read the Help pages first!" message there. Ahasuerus 14:14, 4 Dec 2006 (CST)

So, are we saying that the Beta period lasts from Date X until Date Y, unless something catastrophic happens? And at Date Y we decide whether to leave editing enabled? Alvonruff 14:17, 4 Dec 2006 (CST)

That's what I was trying to define at ISFDB:Beta#Goals. If we don't have closed editing, which we've now agreed isn't worth implementing, then I think we want to define what we want to get out of the beta. I think we want to understand how the tools will really get used, and figure out the improvement path, so we can make the ISFDB/Wiki as effective a combination as possible, while minimizing the risk of discouraging users who sign up and find we don't have everything implemented yet. We want to know what is a must-have enhancement before taking the "beta" label off. And yes, we should have exit criteria that include shut down of non-moderator editing, though that would only be if there were some catastrophe. I can't think of much that would qualify -- perhaps large scale crappy edits that aren't getting caught by the moderators for some reason? But it's an option. I think we're much more likely to take the Google approach, and keep the beta label on for quite a while, until things look good enough to take it off. Mike Christie 16:04, 4 Dec 2006 (CST)

Beta recruiting message/page

How about a beta recruiting message on the front page of the ISFDB when we're ready to recruit? E.g. "The ISFDB will shortly be open for editing by the general public. We would like to recruit beta testers for this effort; if you are interested, please see ISFDB:Beta recruitment"? Mike Christie 19:30, 29 Nov 2006 (CST)

Showstopper Bug Fixes

Mike - I tried to find some of the ISFDB:Beta#Showstopper_Bug_Fixes on ISFDB_Bug_List without luck. Where are these bugs documented? Marc Kupper 12:44, 4 Dec 2006 (CST)

That page documents fixed bugs; the links at the top of ISFDB_Bug_List go to open bugs. Editing bugs are in the 10000 to 19999 range; you'll see the ranges as you go to each open bug page. Mike Christie 12:59, 4 Dec 2006 (CST)

Thank you Mike – I had not paid attention to the links/URLs and had assumed the thing at the top was a table of contents for sub-sections of a single bug list page. I’ve edited the top of the bug list and hopefully it’ll be a little clearer that the actual bug reports are on separate pages plus also edited the ISFDB:Beta#Showstopper_Bug_Fixes section to link to the bug list itself. The more links the merrier!. Marc Kupper 20:19, 9 Dec 2006 (CST)

Project page cleanup

I have archived/cleaned up the Bibliographic Projects in Progress page as per the list of things to be cleaned up prior to beta. Please take a look and see if it's a little less confusing now. Ahasuerus 23:08, 4 Dec 2006 (CST)

That's a big improvement. The other thing I was thinking about under the project cleanup heading was to be sure that we had a link or explanation for every cleanup project that a new editor might be interested in. It might be worth adding some explanatory text similar to what's in the help page about how the Wiki supports the ISFDB. If any specific author or series projects get active, maybe we can list them here too. The only active pages of that kind that I know of are Marc's DAW page and my work on the Fantastic Universe page--your work is more spread out among many others, if I haven't missed something. Or maybe those links aren't needed; people will just find the projects they care about via the links from the ISFDB? Mike Christie 23:50, 4 Dec 2006 (CST)

I added a few sentences from the help. I think this is now good enough; if others agree we can mark this as done on the Beta page. Mike Christie 18:14, 6 Dec 2006 (CST)

I have added links to each writer's ISFDB Wiki page to Most-Viewed Authors - 2005. Since links to non-existent pages are red and links to existing pages are blue, it looks like it should be a useful tool. If color-enabled editors concur, I can add them to other project pages, but it's not urgent and shouldn't delay the beta. Ahasuerus 09:50, 8 Dec 2006 (CST)

Remaining features for beta

I put in the only one I think is compulsory. Any other opinions? Al, is it a big deal to implement the view from the approved edits? Mike Christie 21:07, 7 Dec 2006 (CST)

More on showstoppers

I'd like to add 10056 to the list of bugs to be fixed before we go live. There's no workaround, and it leads to some very odd data. Any objections? I'm going to try to review the showstopper list over the next hour or two and make notes here about any I think we can cut out of that list; I'd like to make it shorter if we can. Mike Christie (talk) 09:51, 9 Dec 2006 (CST)

10010 -- I can't reproduce this; I suspect it's fixed. Here's what I did to reproduce it:

1. Create Test Novel 1 as an omnibus pub containing just Test Novel 1 NOVEL.
2. Create Test Novel 1 as a novel pub
3. Merge both Test Novel 1 titles

Everything seemed fine at the end. Mike Christie (talk) 10:03, 9 Dec 2006 (CST)

I suspect it was fixed as part of the "double-quadruple Pub-to-Title pointers" fix. Moving to "FIXED" for now. Ahasuerus 00:06, 10 Dec 2006 (CST)

10014 -- I don't think this needs to be fixed for the beta. We can just ask users not to enter titles that require Unicode for now; that's not much of a restriction. I think it might not even have to be fixed to exit the beta. Mike Christie (talk) 10:13, 9 Dec 2006 (CST)

10044 -- This is apparently fixed; I retested it with the same sequence I went through when I reported it, and it worked flawlessly. I'll remove it from the beta showstoppers list. Mike Christie (talk) 10:22, 9 Dec 2006 (CST)

D'oh. It is fixed, but wasn't listed as a showstopper; not sure why I thought it was. Anyway, I've moved it from open bugs to fixed bugs. Mike Christie (talk) 10:24, 9 Dec 2006 (CST)

10021 -- This is still a bug, and is certainly ugly, but I don't think we need it for beta. There's no data corruption (or data entry) possible; it's just an ugly crash on a screen that's not used all that often; and the workaround is easy and obvious. Mike Christie (talk) 10:28, 9 Dec 2006 (CST)

10025 and 10028 -- I just tested these, and it appears that the author record is in fact deleted now. I entered a New Novel with Test Author, Test Title, and Test Artist as the cover artist. I deleted the pub and the author title; the author then disappeared, correctly. The artist is still there. I think this is defensible, since the cover record is structured as a work of that artist. In any case, I don't think there's a need to hold up the beta for this; I think we should take this off the showstopper list. Mike Christie (talk) 11:20, 9 Dec 2006 (CST)

10027 -- I can't reproduce this. I tried entering Test Magazine, with a review by "Test Reviewer" of "Test Reviewed Title" by "Test Reviewed Author". Saving that and going into editpub, I tried modifying all the review fields and was unable to get any problems to occur. Ahasuerus, can you recall how you got a problem when you reported this one? Mike Christie (talk) 11:31, 9 Dec 2006 (CST)

Unforunately, I don't have direct access to Al's memories :( Ahasuerus 02:18, 10 Dec 2006 (CST)

10032 -- I think 10011 covers the part of this that's important. It's easy to fix the variant title issue; just do a MakeVariant on the "grandchild" and the problem goes away. The awards problem is a loss of data, so that's a showstopper, but that's covered by 10011. Of course it may turn out to be the same fix, but I don't think we need to list 10032 as a showstopper. Mike Christie (talk) 11:51, 9 Dec 2006 (CST)

10038 -- This is certainly ugly, but there's a workaround and it's caused by entering invalid data. Seems pretty harmless, particular if the moderators are doing their jobs. I think this can be taken off the list. Mike Christie (talk) 11:55, 9 Dec 2006 (CST)

10039 -- I can't reproduce this. I tried New Novel, and changed the type to chapterbook; everything worked fine. I did notice that the Nesbit title reported as in error is now a COLLECTION, so maybe the data's been edited since the bug report. I also noticed that there is no title reference on that record, so perhaps that's a relic of the error, whatever it was? Ahasuerus, can you reproduce this? Mike Christie (talk) 13:00, 9 Dec 2006 (CST)

Actually, it's listed as a Chapterbooks at the moment. Are we looking at the same Publication? Although it doesn't error out any more, the fact that there is no associated Title makes me wonder if there are still problems with Chapterbooks. Ahasuerus 02:28, 10 Dec 2006 (CST)

Here's the list of bugs I think are showstoppers. I've removed anything I couldn't reproduce and anything that appears to be fixed, as well as bugs I don't think are serious enough to stop beta. I added one bug, 10056. I also dropped 10022 since Al says he thinks it's fixed.

• 10011 - Awards info needs to be migrated with title merge. This loses data.
• 10023 - Merging variants. This loses data.
• 10056 - Incorrect anthology data management; no workaround.

-- Mike Christie (talk) 13:06, 9 Dec 2006 (CST)

Getting ready for Beta

Al is about to work on killing bugs, which is great news. There's not much left to be done before beta along those lines -- my list is just 90044 and 10023 -- but Al's expecting to get a lot more than that done.

I think we ought to open up for editing as soon as those two things are implemented. We want to go live at a time when Al has bandwidth for the next week or two, in preference to going live when he's used his bandwidth up for a while.

So here's my list of specific tasks to get done:

• Main page announcement
• Beta recruits page -- link from main and from the Beta page. It should just point to help pages, to a list of moderators, and ask for feedback and criticism
• Announcement on ISFDB front page
• Post a note to rasfw

When 90044 and 10023 are done, I suggest we do these things right away, and open for business. Mike Christie (talk) 14:34, 15 Dec 2006 (CST)

I think we'll need to discuss 90044 (being able to view old submissions). This isn't too difficult for rejected submissions, as the submission didn't alter the database (it was, afterall, rejected). For submissions that are integrated, we can't display split screen data like the moderator sees.

If a submission changes the title from "Old Title" to "New Title", then the moderator tool picks up the current title ("Old Title") from the title record and displays it on the left, then picks up the new title from the submission ("New Title") and displays it on the right. So far, so good. After the submission is approved and submitted, the title record is modified, and the title is now "New Title". If we were to look at the submission after integration, then the moderator tool picks up the current title ("New Title") from the title record and displays it on the left, then picks up the new title from the submission ("New Title") and displays it on the right. Now it looks like the submission changed "New Title" to "New Title" which isn't what happened. The old title isn't stored anywhere (it's not stored in the submission record because it would complicate the format, and it's not needed for edits). This is why there aren't links to the submission records in "Recent Edits".

I think rejected submissions would be better served with a "re-edit" tool (which I wouldn't mind being able to invoke from the moderator screen as well - sometimes dissembler has a minor problem I wish I could just fix right there, without integrating and then going back and re-editing the results). Looking at what was changed is related to the watchpoint problem - we probably need some kind of fine-grained history tool that tracks the field changes in specific records. Alvonruff 16:08, 15 Dec 2006 (CST)

The functional problem that 90044 is supposed to solve is visibility of what has been done to the data. Even a log file would suffice; that is, each "Approve" writes a text version of the activity to a flat file that has "#124823" or whatever at the start of each edit log record. Without this, I'd be very unwilling to do any edits at all, as I'd have no idea whether they were being changed. Is the log file easier? Is there some other way to do this? Mike Christie (talk) 16:29, 15 Dec 2006 (CST)

Or how about this: take the raw html for whatever is displayed on the approve screen, and if approved, save that to a record indexed by edit number. Then just redisplay that html on the query. No intelligence needed. Does that work? Mike Christie (talk) 16:30, 15 Dec 2006 (CST)

I think I can add a new table that tracks "to" and "from" for fields fairly efficiently. This best thing about the feature you're looking for in general is that it bolts onto the side of current database, regardless of how it's implemented, so it shouldn't destablize any of the apps. I'll see what I can prototype up in the next 24 hours. Alvonruff 19:39, 15 Dec 2006 (CST)

Editor recruitment

Speaking of editor recruitment for the beta phase, we have a test case, er, I mean a brand new and [http://isfdb.tamu.edu/wiki/index.php?title=Special:Contributions