I think it would be a good idea to enhance our database by including boards as entries. Boards have always been an important part of the different scenes up to the second half of the 1990s, many demosceners have been (co-)sysops, most demogroups had BBS affils, many coded BBS intros etc.

I have been setting up a BBS database within pouet some five-six years ago when PS was so kind to code the infrastructure for it: http://www.pouet.net/boards.php -- however, with Demozoo this could become much more amazing.

I propose the following content categories for within a BBS entry:

NAME: BBS Name (alternative names, as with groups, should be allowed since some boards renamed themselves over time)

LOCATION: Use the same location engine as with individual sceners. I am very much against having a field with telephone numbers, because even if a board was 100% leagl, this still could be unpleasant for the former sysop (or annoying for the poor people who own the number now).

STAFF: This could be done in the manner of prod credits, but with following pulldown roles "Sysop", "Co-Sysop".

AFFILS: Also like prod credits, but with groups, not sceners, to enter. Following pulldown roles: "WHQ", "HQ", "Memberboard", "Distsite"

BBS INTROS: Possibility to link prods, like invitros are linked to parties.

TEXT ADS: Possibility to upload textmode BBS ads and probably display them with Ansilove.

This is just a suggestion, of course, and I am no coder, but this is not that hard to achieve, is it? And the value to scene history preservation would be immense.

Alongside the 'delete production' button, add the option for admins to change the supertype of a production between graphics/music/production. Currently this has to be done through the Django admin.

This issue is a merger of Trac tickets #37, #110 and #137 (the latter was closed as a dupe for #110).

In short: We need functionality to specify productions' relations to each other - for graphics used in productions (much like our soundtrack functionality today), for productions that are remixes of others (think of the "pirated demo competition" at certain parties or remixes of soundtracks), but most importantly for Demopacks - prominent productions of the early amiga and atari scenes.

Quote from Trac; "Me and Gasman had discussions about this at Revision off-list, if memory serves. We agreed that we'll implement this (post-launch) as relations between productions, and that that in turn would allow us to cover both "inspired by", remix and "featured on pack"/"this pack contains" situations."

I know for a fact that Lotek and Saga has had inquiries about such functionality since launch, and that I would very much like it myself, to aid in the cataloging of packs.

A spinoff suggestion from #23 - as soon as a name is entered, we can do an AJAX lookup on it, and if it matches an existing group name, we can:

1. warn them that they might be entering a duplicate
2. invite them to fill in the 'differentiator' field. (To avoid confusion, we can hide the differentiator field from ordinary users in all other circumstances.)

(Strictly speaking, if this is the first time a collision has happened for a particular name, we'd also ideally want to set a differentiator field on the existing group. But prompting the user to do that would get quite messy and confusing, and we'll find/fix it sooner or later through the maintenance reports anyhow.)

If different parties within the same series are located more than (say) 100km apart, that's a strong hint that they're actually not the same party series at all, but separately-organised series that happen to share the same name. We should therefore have a maintenance report to allow us to identify and fix those cases.

From discussion on mailing list, by Gasman;

"Ah yes, this subject came up when I was setting up Twitter cards https://twitter.com/gasmanic/status/417141211271401472 - I had to specify whether images were likely to contain 'mature content', and couldn't in good conscience leave that unticked. (It looks like Twitter only supports that as a site-wide setting - there's no way to mark particular images as clean or not - so any Twitter user who has not previously clicked through their 'mature content' warning message will get that on every shared image from Demozoo. Given the choice, I'd rather fix it so that NSFW images are left out of Twitter shares, and then we can tell Twitter that our images are safe.)

Obviously, we'll have to think carefully about default settings for this option. My preferred approach would be:

• All images are 'undetermined' by default; admins can change this setting to 'safe' or 'NSFW' (I imagine doing this with a maintenance report: show 100 screens at a time, scroll through them marking any NSFW ones, and submit; any non-marked ones then become 'safe')
• For non-logged-in users, only 'safe' images are shown. (Images that are not 'safe' will be hidden completely; there will be no 'ZOMG YOU NEED TO LOG IN TO SEE THESE BOOBS' warnings)
• We add a 'Show NSFW images?' checkbox to the registration form; this will default to 'no' for new users, and 'yes' for existing users.
• Users who have NSFW images disabled will see images that are marked as 'safe', plus 'undetermined' ones that they have uploaded themselves (so that we don't get people going 'wtf, where did my screenshots go?'). Also, there will be some sort of notification on the screenshot upload form whenever that prod already has screenshots that they can't see (so that they don't unwittingly add duplicates)."

Following on from #23. (Originally this report was put in so that we could deal with group names that were created with "Foo (bar)" notation before we implemented differentiators. Now that we're public, other people are trying to enter group names like this, but being less consistent about it...)

Let's say prod A is in some compo result table, but there's a dupe entry B that is much better (maybe because it has screenshots, credits and whatnot) but isn't linked to that compo. I'm not sure how this replacement is supposed to be done "properly" right now... Adding a new table row and deleting the old one? Sometimes you are able to still edit a table entry, but sometimes you can't modify it by clicking on it. If this was more consistent, it would probably make such replacement tasks simpler. On the other hand, I'm not sure how important this is if we are going to get a proper dupe merging functionality anyway.

This has come up several times in discussions, and obviously needs to be handled sensitively. It was suggested that they could have a cross next to their name (although as a religious symbol this is contentious in itself...) or a 'flag' like AMP: http://www.amp.dascene.net/newresult.php?request=country&search=79 .

Further comments from Dipswitch:

Now I know this is a controversial topic, and the old "list of deceased sceners" page at Scenewiki got shut down exactly because of that. It's obvious that it does not honor the memory of the deceased if the cause of their death (especially if being suicide or drug OD etc.) is up there on the internet. However, it is completely legitimate and, moreover, necessary for historical purposes to know and to note down whether and when a scener has died. We don't need to know any details, we just need to put down the fact and the date. It is, for example, important for dealing with double nicks (e.g. if we know that Superscen3r died in 2007, we for sure know that a "Superscen3r" who released a module in 2011 must be a different person).
My suggestion is: We introduce a tick box "deceased" which is visible for admins only, thus preventing any abuse, accompanied by a field where one can enter a date (limited to year, exact date might be too much private information). The result could look like something I did for Crest manually in the notes: http://demozoo.org/sceners/36009/

ModArchive song links are already recognized and converted to permalinks. The same should be done for "ModArchive Lite" links, since people have already used them in our DB.
http://lite.modarchive.org/index.php?request=view_by_moduleid&query=105002
and
http://lite.modarchive.org/module.php?105002
Should be automatically corrected to http://modarchive.org/module.php?105002

The same could be done for Orgasmod links, which look like this:
http://orgasmod.com/index.php?request=view_by_moduleid&query=105002

reported by the_Ye-Ti on IRC: http://demozoo.org/productions/37602/ is tagged "dark ambient", but http://demozoo.org/search/?q=dark+ambient returns no results. Could be tripping up on the multiple words, perhaps?

In Safari version 6.1.1 (7537.73.11)* if you upload a new screenshot for a production it presents a loading indicator in the screenshot space which doesn't seem to go away. If I refresh the page, the image appears.

* The browser I used, it may be a problem in others.

Demozoo periodically (every few weeks) logs me out, and I usually notice this while I'm trying to edit something. So I'm using the login box at the top, enter my credentials, and after that I'm redirected to the frontpage. It would be much nicer if the user could be redirected to the last site they visited instead.

Mentioned in #29, but deserves its own ticket :-)

"...for a project at work I used the jquery library Tag-It http://aehlke.github.io/tag-it/ (not to be confused with the Django library Taggit, which Demozoo is already using :-) ) which provides a more intuitive input field, has support for autocomplete suggestions, deals nicely with the minefield of different ways of entering them (comma-separated, space-separated, quoting for multiple words) and turned out to be really easy to integrate. We should definitely use it, and solve a lot of our tag-entry problems in one go... "

Lightboxes have overflow:auto set, meaning that popup elements (such as dropdown lists) are constrained within the lightbox and create scrollbars. For example, on the 'add credit' form, try entering 'Alex' as the nick and opening the 'Alex' dropdown that appears...

(comment from langhuxley: That's entirely logical, given the overflow. The trick is to place the ul that poses as a form select outside the container of the rest of the lightbox content. Overly verbose divitis is the answer to that one :) )

In short, would it be possible to attach a small note to a tag, so that for instance clicking the tag "Beertime" would not only list all productions with that tag, but also display a small note (if present), with some information? In the case of Beertime it would read, e.g., "Beertime was a series of c64 demos released by the finnish demo group Dekadence." or something similar, but it could be applied to lots of different tags to add some context to things.

If/when we implement sceneid, we do not want just anyone to be able to edit a user's pouet-profile link (effectively changing the "owner" of the profile).

Some sort of restriction should be put in place, so users can only ADD a pouet-profile, and not edit or remove it without further ado.

From Trac tracker issue #133;

"[21:08} ltk_tscc: btw... is is possible to enter two sceners+crew? xxx/crew + xyws/crew2 ... it always screws up when i try this
[21:08] gasman: ltk_tscc: no, that's not supported... maybe it's something I can look at in future, but for now it would be adding too much complexity
[21:08] Saga_Musix: oh yes, i was going to suggest that too

(this would be a BIG job... restructuring the data model so that affiliation lists are attached to individual authors rather than the production, and updating the byline parser/widget code accordingly)"

When entering prod authors, a 'scoring' system is used to select the most likely candidate among multiple sceners/groups with the same name. For example, in a byline like "Abyss / FC", there are several possible sceners / groups called Abyss and several groups that abbreviate to FC, but when going through the list of 'Abyss' candidates it will give extra points to ones that are a member of a group known by the name FC - and usually find a single 'top' result.

On entering credits for a prod, this 'scoring' never happens, because you're only entering a single name rather than a name/group combo. To improve this, we should pass in the group name from the production's overall 'by' field and use that to influence scoring.

Example: Adding a credit for 'Defjam' will suggest Defjam the scener and Defjam the group with equal weighting, forcing the user to pick one manually. However, if the credit is being added to a Checkpoint demo, then Defjam the scener should be awarded a higher score for being a member of Checkpoint, and thus get picked automatically.

(If you can make this work for auto-completion too, so that simply entering 'd' would suggest the one member of the group whose name begins with D, even better.)

Recognise Aminet download URLs as a specific link type and display the list of mirrors as we do for scene.org.

Note that aminet.net also provides an info page much like scene.org does, e.g. http://aminet.net/package/demo/mag/ays-snd1 - and these have been entered as the download link in some cases. Unlike scene.org, however, it is not possible to directly derive the direct download links fro this URL (as it doesn't tell us the file extension). I therefore propose to ignore those links here. (We could conceivably set up a background task that scrapes these info pages... but that's a job for another time)

Have a background task to periodically fetch download links and flag up any broken links -in a new maintenance report, and/or emailed weekly to admins.

Originally submitted by gasman 2011-05-16 on the Trac server.

(moved over from trac, ticket #120 on there)

To distinguish things like video captures, party vs final releases, disk 1 / disk 2, and so on.

comment from trac ticket by Saga Musix: This has been requested on the forums as well by now. Would be really useful to have. :)

Also discussed with Bombe on irc 2014-01-09.

MIgrated from issue #158 on the trac-server.

Menace: "What the topic says; the current system apparently leads to situations like this, where the latter is spelled with a capital K in the tag itself."

http://demozoo.org/productions/tagged/4klang/
http://demozoo.org/productions/tagged/4klang_1/

Gasman: "Makes sense - ticketed. On the subject of tags - for a project at work I used the jquery library Tag-It http://aehlke.github.io/tag-it/ (not to be confused with the Django library Taggit, which Demozoo is already using :-) ) which provides a more intuitive input field, has support for autocomplete suggestions, deals nicely with the minefield of different ways of entering them (comma-separated, space-separated, quoting for multiple words) and turned out to be really easy to integrate. We should definitely use it, and solve a lot of our tag-entry problems in one go... "

Video more tightly embedded in the browsing experience, right in along with the screenshots. Support is planned for YouTube, Vimeo, Capped.tv, Demoscene.tv and dhs.tv.

We need a way to render ascii and ansi files for web use, in order to accurately display various text files associated with productions (results, .nfo's), ascii and ansi collections, and file_id.diz'es etc.

We will probably implement Ansilove ( http://ansilove.sourceforge.net ) for this purpose, but it also brings up an issue of how to incorporate these features into the overall design (there would need to be things to click on to show nfo's for a prod, for instance).

We probably do still want to show them in the usual screenshot panel, and have them open up in a lightbox - but they should be shown in full resolution, with a scrollbar.

Ticket originally opened by gasman 2011-05-24, and content by myself and gasman.

When one clicks edit on Tags to add a tag, one has to additionally click inside the ensuing tagbox before oen can type anything. It would save a click and be more intuitive if you could just start typing right away.

Upon adding a new platform for Thomson - http://demozoo.org/platforms/53/ - I became keenly aware that there are some design issues with the current layout - most notably the fact that there is no border padding for the image, making text crush up against it.

It would also be preferable with the image right-aligned, so as to not break text formatting more than necessary.

On some productions we have screenshots which are worth keeping for completeness, but not 'interesting' enough to be used in a wider context across the site (e.g. as thumbnails in prod listings, and on the 'party series' page) - an example would be screenshots of C64 disk directory listings with nice PETSCII art.

To do this, we would extend the 'Manage screenshots' interface (see also #11) to allow specific screenshots to be marked as 'featured'. On prods where this is set, thumbnails would be picked from the featured screenshots, rather than the entire set.

Go to the edit form for a production by a group with an ambiguous name. Make any edit to the byline field (e.g. add some whitespace). This causes the previous state of the group dropdown to be forgotten, reverting to the 'warning sign' state.
We could fix this by capturing the current nick IDs from the dropdowns before making the AJAX call to refresh the field, and pass them in the URL to instruct the automatcher to favour those nicks above all others.

Past experience with question-answer CAPTCHAs on other sites suggests that spammers will occasionally use human input to answer them, then add the answer to a database so that it can be automated. By keeping a log of the question that each user answered on signup, we can find out which questions have been broken, and replace them with new questions.

(Suggested by Saga Musix)

http://recoil.sourceforge.net/ - includes a decoder plugin for Imagemagick, which means we ought to be able to use it from Python via the Wand library http://docs.wand-py.org/ . We're already dealing with PIL and pygame (SDL_Image) as image conversion backends, so adding another one won't be too much of a stretch.

End result: we get to support several hundred new image formats, both for screenshot uploads and extracting images from graphics releases. IIRC, it means we can also ditch pygame (which I think we're only using for LBM image support), which is really nice because that's a pain in the arse to install.

There are a few cases creeping in of people using brackets in group names to indicate abbreviations or differentiators (platform/country) - see the admin report at http://demozoo.org/maintenance/group_nicks_with_brackets, although people have used square brackets too so we need to catch both types.

We could add a bit of Javascript so that whenever someone puts brackets in the name field, we pop up some extra help text, along the lines of:

Are you sure this group name has brackets in it?

We welcome the extra detail, but we want to make sure it's in the right place. If this is an abbreviation, please put it in the 'Abbreviation' field - if it's a country or platform detail needed to distinguish it from other groups called [name of group], put it under 'differentiator'. If this really is part of the name, carry on as you were :-) If in doubt, ask us on the forums!

(Note: check whether ordinary users get the differentiator field. I have a feeling it might be admin only...)

Apparently links to amigascne.org/old/ are still showing up in the database, despite Menace systematically fixing them a few months back - probably due to people blindly pasting in download links from Pouet. amiga.nvg.org is another dead host that we've now fixed all links from - in both cases, we have reports in http://demozoo.org/maintenance/ to tell us if they reappear.

We should add a bit of javascript to the 'edit download links' form to check the URL against 'known bad' hosts, and if it matches, display a warning message to the user telling them to check their links.

Add one or several dummy fields to the user registration form - initially empty, hidden in CSS, and labelled with an instruction (also hidden) not to fill it in. If the form is submitted with anything in those fields, reject the submission as it's probably a bot.

(Suggested by Saga Musix)

Kind of backwards from the way you'd normally do it, but can't hurt to add it as a feature: have an 'add production' link in the 'featured in...' box, allowing you to select a production to associate this bit of music with. (In this case, we wouldn't do anything meaningful with the 'ordering' field - if that was important, someone would have to go to the prod page and fix it.)

Allow users to modify the order in which screenshots appear in the carousel.

We have a 'manage screenshots' interface which is currently locked down to admins only, since the only available action is delete. It would make sense to extend this interface to allow drag-and-drop reordering, and make it available to regular users for this purpose.

We keep a local copy of the scene.org directory tree in the sceneorg_* tables, for use in the compo file matching backend. We could use this to identify broken scene.org download links on prods (which are broken either because they were entered through the compo matching interface and subsequently moved/deleted on scene.org, or simply because someone entered it manually and screwed up). This would make sense as a new report under demozoo.org/maintenance/ .

Upon clicking the edit button for Downloads, the ensuing lightbox always has the first link marked - making it a bit too easy to just click ctrl-v and enter before you have a chance to think about it, and possibly overwriting an existing download link. IMHO the default behaviour should be that a new, empty field should be the default landing point, minimizing the danger of accidental deletion of information.

Add an image upload field on groups and parties, similar to the screenshot uploader and presented in a carousel view. This would be used to display logos and other source material such as adverts and votesheets - Menace has agreed with Tony of www.sceneletters.com that we are free to use his archive of paper invites.

We should make a decision about exactly what sort of imagery we collect - presumably we don't want it to become a general photo gallery.

We look terrible on mobile (phones and tablets), as "reported" by Ziphoid to me on irc today. In practice, the site is extremely hard to navigate on such screens since the design breaks so badly.

I was quite sure we had a trac ticket for this, but I can't find it.

...instead of having to go through a compo results listing. (Would need some special handling of rankings to ensure they get inserted in the correct position - normally ordering is done manually)

The database will tend to preserve the order in which authors / affiliations are entered, but doesn't guarantee this - so well-known pairings like "Fit & Bandwagon" may occasionally show up as "Bandwagon & Fit". To fix this, we'd need an explicit ordering field on the author_nick and author_affiliation_nick link tables.

Group memberships are associated with a scener record - unlike production authorships/credits, which are linked to a specific one of their nicks. Most of the time, this is what you would want (so that if a scener changes his name, the group member list reflects the most up-to-date name), but there are some cases where you want it to be 'pinned' to a specific nick - most commonly, joke groups consisting of established sceners all adopting an 'alter ego' (Nextempire, Elitegroup, HiRMU).

I'd suggest implementing this as an optional (nullable) nick_id field on the memberships table: if this is set, the members list will display the referenced nick, otherwise it will show their main/default name. The two 'add/edit membership' forms (i.e. adding a member within a group page, and adding a group affiliation within a scener page) would be extended to add a new field, labelled something like

Within this group, they are known as: [...]

where [...] is a dropdown containing the options 'their usual alias' (the default, equivalent to setting the nick_id field to null), followed by all of their nicks. (Question: Does this wording make it clear enough that they should only be using this field in exceptional cases - not just routinely selecting the best-known name because it's there? At any rate, we should probably only be showing this new field whenever the scener has two or more nicks.)

Create a maintenance report that weeds out download links from known "unsafe" sources, like DropBox or Google Drive download links that tend to expire, Such a query would grep all the download links, looking for matching hosts. It would probably also be good if the hosts could be edited by non-coders, to make maintenance easier.

Roughly speaking, any place we'd have screenshots/thumbnails, music releases should have a player widget instead.

This will require mirroring tracks on S3 (because all major archives are FTP-based, which isn't supported consistently by browser audio facilities - and in any case, they're frequently packed inside zip files) and possibly re-encoding them too (as mp3 and ogg for cross-browser support - also, bandwidth considerations may mean that it's only feasible for us to offer low-bitrate versions, or <1 minute clips). For MODs and more exotic formats, we'll need to either render to mp3/ogg or look at client-side solutions (jsmodplayer is making good progress right now...)

Something that would be really nice would be to have metadata from music that applications can use to request data. For example a musicplayer can calculate a hash (sha1, md5, etc) and request the info from demozoo about the music. This would be esp good for modules and similar formats as they need to be replayed differently if created in Protracker 2.3, 3.x, etc. Also the metadata can contain info like which demo the music was used in.

We frequently encounter cases where two scener records turn out to refer to the same person, and need to be merged. Currently this is done manually, by moving all releases / credits to one of those sceners (possibly under a newly-added nick) and removing the other one. It would be nice to have an action to do this in one step.

This would most likely be an admin-only feature, as it would be easy for a malicious user to trash the database by using this excessively (and rather hard to extend the logging mechanism to capture all the information required to revert such actions).

In terms of implementation - you could get most of the way there by updating the releaser_id field on all of releaser 2's Nick records to point to releaser 1. That would then leave things like group memberships, real name, location and external link records to deal with - you'd either have to devise a custom interface to specify which items should be moved, or leave those for the admin to deal with manually.

Moved over from trac issue #123.

There are lots of productions out there (especially in the old days) that were released AT parties, but not as part of the main competition. We need a way to make sure these are clearly signposted as out-of-compo releases.

Asked about on the forum here; http://demozoo.org/forums/31/

The search box offers a dropdown menu with suggestions after one has started typing. However, those suggestions cannot be middle-clicked, which makes them only really useful if the result is not ambiguous.

http://demozoo.org/graphics/17414/ - presumably the uploaded version of the image had a border on the first frame, and no border on the second (so it got shifted up/left, leaving some junk bytes behind)

It's debatable whether we should allow animated GIF screenshots - Spectrum screenshots using the 'flash' attribute are one place where it's appropriate to use them. Graphics compos that specifically permit animated GIF entries might be another (no, animated GIFs can be 10s of megabytes in size; we should be taking screenshots OF them, not treating them AS screenshots)... other times we could probably assume it's a Pouet-style slideshow and should be split into separate screens. Either way, we should either cleanly accept or reject them, not fall over at the processing stage.