Current request queue

It would be nice to see what bands are currently in your request queue -- among other reasons, so that we don't duplicate effort. Certainly for this to not add much overhead to the submission process, it would have to either be automatically generated, or else very minimal, but that would be OK.

If only you could see our email accounts... there are probably 75-100 bands waiting for us right now.

Well I know my pending submission has 26 of those, so... :)

I don't like submitting more bands when there's still an outstanding submission of mine, or I could seriously give you guys 70 bands a week and flood you. But it would be interesting to see what other stuff is in the queue.

I was thinking more about this the other day and wondered about the possibility of having a submission form on the webpage itself. It would have separate fields for all the stuff you need, such as name, members, artwork URL, etc., so it would force people to provide all the info. The submission processor could automatically check submissions to see that they (a) weren't already in the database and (b) weren't on the list of rejected bands. Then it would stick the submission into the queue and add it to the list. We'd get to see your queue, and you'd get a standard format that the submissions would all come in, with an easy way to add more verification or requirements at a later date.

Pk,

That's a damn fine suggestion. We currently have a web form that we use to enter in data and check for errors which I guess could be expanded to a public domain use which would put the data into a queue for us to review before final input. I've got a couple of new features that should get added to the site in the coming days and once I have those online I'll look into this. Good call.


Kevin

... makes more work for us humble researchers in the field, but what the heck ...

One problem I can foresee is a later more accurate submission would be rejected in favour of an earlier incorrect one. But that's a minor quibble.

I'm not sure how it would make for more work for submitters. Your submission is already supposed to have band name, album name, member list, connection to existing tree, cover art, and verifying web page(s). Now that release year has been added we should probably be submitting that too. If you don't have these when you submit, then at the least you push the work onto Mark + Kevin, and at worst they reject your submission.

I am a bit concerned about submitting chains of bands, which I do frequently. If the submission processor verifies the connection to the existing tree on every submission, then I have to submit only bands that immediately link to the tree, and extend the chains once those are approved. But having verification is nice. I think what I'd like to see is "connection to existing tree" accept a link, which can either be a page (artist page presumably?) already in the database, or the entry of another submission in the queue.

The issue of how to make corrections or additions to the database is worth thinking about. My suggestion would be that at least some pages on the site have a "correct this entry" link/button or something. Doing that would give you a form with all the data filled in, which you could change as you saw fit. The requested would then stick that in the queue (maybe a different queue?) for verification. I would make use of this to add nicknames and/or release years to releases that don't have them. I'm not sure exactly where the link would go or what it would look like, though. Have to be careful, UI-wise, about not providing too much information and too many links in the same place.

Incidentally, both these submission form things should have a free-form "Notes" field so the submitter can explain the corrections being made or anything special about the new entry they're submitting.

PK, have you been spying on us? We already do just that behind the scenes with a field called Notes to document the justification behind each entry into the database. The URLs and explanations that all of you send us get stored there.

... so how easy (or desirable) might it be for there to be a read-only window into that structure? Then we could see what was going on under the hood and we'd have even *more* reasons for avoiding work ...

PK's suggestions are once again very good. It would probably be a good thing in cutting down redundancy to allow a submission form for the general public so that we could then read the queue and accept / reject the submission directly rather than cutting and pasting information into our administration page once we verify the data. I also am very taken to the 'wiki' style user data correction for individual records (or to just add release dates). These features would probably make everyone's life easier in updating the site and I'll start working in that direction.

I would like everyone to please be aware that code base and infrastructure for the site is really starting to get big as I'm able to implement more and more features. One of the drawbacks of having the snowball get bigger and bigger is that it starts getting harder and harder to move, or make adjustments in this case, as there are far more things that can break when a change is made. That's why it took me so long to get the new 'Create Map' function working when on the surface it may seem a minor expansion of it's ability. I have to go back through and make update larger and larger swaths of code to keep everything running. I'm not complaining whatsoever, I love seeing new features and additions being added to the site, and while I'm always pleased to hear new suggestions for improvement I just want to warn everyone that the implementation time may start slowing down as I try to manage all the code. So while I fully encourage suggestions, comments, etc please be aware of this fact and I hope no one gets frustrated or discouraged if it takes some time to get these features fully implemented. There's only so much time I can work on the site in a day. Thanks.


Kevin

Kevin, have you ever considered open sourcing some of the code for the site? It probably would have little effect, but in a perfect world one of us other coders might be able to help you clean up/refactor/expand the codebase.

Possibly unworkable though, depending on how your codebase is spread out ("So, I've got these 10 CSS files over here, and these 3 CGI scripts, and this SQL database layout here, ...")

Anyway, thanks once again for all the work you put into the site. It keeps getting better.

Oh, and I really like the idea of being able to edit band pages in-place, as I could just fix a ton of minor bugs and add release dates without wasting you guys' time.

PK,

I've considered going open source however at this point in the game managing an open source project would probably be tougher than just taking care of everything myself. When you start dealing with CVS repositories things can get pretty hectic so for now keeping things simple, methotical, albiet a bit slow on occasion, would make my life much easier. I'm not saying it won't happen but it won't be just yet.


Kevin