-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This page may get broken up into sub-pages but for the moment it is all in one. Please avoid "should" and "try to" in proposals, as even not fully fleshed out ideas are easier to provide improvements and suggestions for if they describe something explicitly rather than possibly optional.
In this document, if something applies to both moderators and admins, they will both be referred to by the title of "staff" to avoid writing it out.
This section is for things we definitely do not want to keep from the existing implementation. If you have an improvement for an existing feature to fix something you don't like, then it goes in the Proposals section.
Reasons why not:
- Not enough forewarning
- Many users only found out when they tried to queue a song and failed to so
- If they didn't pay attention to their notifications, they might stay bewildered
- Too long (took up an entire hour)
- Too many complaints (various combinations of the above, and more)
Changes outlined below in the Proposals section will help tweak DJ Random so there is no need to inject a large block of "mandatory fun."
This section is for things we won't already implement in the course of building the new website (like having song pages, etc.) that we want to keep from the existing implementation.
It is able to play various Scener file formats (trackers, etc.) natively and allow us to tweak their playback without needing to re-record a song. maep spent a lot of time and effort making this work very well. It also makes it easier on contributors as we can say "Just upload the module! The site will take care of it."
They're sometimes cheesy, but people like them.
It should go without saying any new site would have one, but these days many sites are built without shoutboxes or oneliners and all dozen of us who talk way too much on the website would be sad without it. Might be nice to make the "Chat" page a first-class citizen in the app (ability to be properly styled and in the same orientation as on a normal desktop page) for when we have mobile-abled themes that may omit the oneliner on most pages to get as much space back as possible.
They need some enhancements, outlined in the Proposals section, but it was nice that anyone could easily add links to other sites or places that may provide more information or download links.
The existing code supports OpenID, but Google (and others) switched to OAuth2, so we should keep the idea but update with the times.
It seems useful to have an instance that is easily set up for people who want to develop on the site, regardless of whether it be client or server-side.
This is where all the features we want to see that we don't currently have go, and also improvements to existing features.
For lack of a better inclusive term, this includes the ability to pause the standard stream based on user requests to play something else. This needs to be able to:
- Schedule a temporary patch in of a live stream from a demoparty to stream a music compo, for example
- Allow staff to schedule complete play-throughs of compilations
In allowing these, the site must:
- Require at least 45 minutes advance notice to schedule a show
- Visually indicate to users and visitors of upcoming shows (on any page, where possible)
- Prevent users from queuing a song if it would end up playing during a show (The current code may let you make the request, but holds it until the show is done)
Rules should be simple and easy to summarize in a single oneliner message if anyone is asks, though it should also have an FAQ entry.
Rules:
- When asked to play or request a song, it will randomly choose from a pool composed of the following song groups:
- unlocked, length < 7 minutes long, and have an average rating > 2 stars
- not played in the last day and have < 5 votes cast
- It will play a song if the queue is empty and the currently playing song finishes
- It will request a song if a jingle just played and the queue isn't empty
When requesting a song after a jingle, is to be processed and behave the same as if done by a regular site user. If no song passing the above criteria is found after 10 attempts, the last failed attempt will be used. (This will only show up in instances with low song counts and avoids dreadful dead air.)
The current code makes a few properties of this algorithm configurable such as the agent's name and the max song length to filter by. There's no reason all of the numbers listed above couldn't be configurable in this version.
The site should have a single unified approval queue for all requested site changes, including uploads of new items, with the exception of songs, which will have their own queue. This will make it harder for staff to forget, or purposely ignore, things which aren't songs or info updates, like images, new artists, etc. These requests should also be better formatted to highlight what changed and avoid displaying related parts which did not change.
Approvals or rejections of requests (at least songs) requires 3/5ths of all staff who have acted on a request in the last three months. (This is to avoid waiting for people who got made staff but became less active.) To cut down on clutter, a request will be removed from the request queue of all staff who haven't dealt with it yet when they load or refresh their queue once enough actions have been noted on a request.
Staff must select from a small list of categories when rejecting a request, which will be aggregated and sent to the user when enough actions have been reached, so they have an idea why it wasn't approved. (Approvals will just note it was approved, as before.) These categories may be things such as "Too low fidelity or bitrate," "Violates site policy," etc.
Users can make a single appeal to overturn a rejected request, as long as they provide at least one new piece of information. This includes adding info to a field not previously populated, changing an existing one, or putting more info into the request comment box, which will be visible to staff only. (This comment box exists in the current site as well.)
Users can appeal a rejected appeal to request manual review by admins, the decision of which becomes final. This might be abused by those who perennially submit items which get rejected and could be annoying. The last three paragraphs and the following paragraph are more important.
Users with a minimum of 9 requests in the past 45 days with 2/3rds or more of those requests rejected will be prevented from submitting new requests. Approved appeals supersede the original request's rejection and count as an approval, not a rejection. ex: a user uploads 9 things, and staff reject 6 out of the 9. They now have to wait for at least one of those rejections to become older than 45 days.
As before, a single staff can approve or reject a request, though a reason will be required. All requests, their final state (approved, rejected), and who approved or rejected it will be stored in an admin accessible way. (The existing site only logs the date and initiating user of changes made via the django CRUD backend.)
All approved requests' date and submitter (editor) will be made accessible to all users via the appropriate page linked to the object page the request was about, where possible.
Users will be able to submit a request to claim ownership of an unlinked artist page. The request will have a comment box visible to staff only to indicate why we should let them be linked with it. Notes on the request submission page could include suggestions, for example, to link to a tweet on their official account using some "private" info they put in the comment box. Approval of an ownership request results in the requesting user being linked to the artist the request is about, and rejection will result in no changes.
Being linked with an artist page lets a user make edits to the page and items linked to the page, such as songs, that will go live immediately, but add a request into the uni-queue for review purposes. Instead of "accept" and "reject" buttons, these review requests will say "do nothing" and "revert", instead of "accept" and "reject," as the edits are already live.
Users linked with an artist page will be able to automatically change the status of linked songs to "removed by request" without generating a review request. Songs "removed by request" are unable to be queued.
Artist pages will be enhanced to allow them to be compositions of two or more artists, for situations like xyce where the sum is greater than the parts and it is not a demogroup or simply a "long collaboration." Users linked with an artist forming part of a "superartist" will gain edit rights, as noted above, to the "superartist" as well.
Staff can create and edit the types of links that can be added to items, and which types of items they apply to. (The existing site has this feature, but we're going to go further.) This system will allow staff to also indicate what kind of link it is i.e. part of a list of linkified icons, linkified image pulled from another website, or a plain text link with a user-given label. This is to avoid having special features built into item objects for things like Pouet IDs or user Twitter accounts and make it easier to update common link types easily if the target site changes their API.
The UI for adding an extra link will be changed to show already applied links, allowing a user to request an edit or to remove them, and new links as added by the user instead of a large table full of blank empty boxes. This is to help avoid having two links to Pouet or Demozoo on an object because a user didn't realize an empty field meant the website would add a new entry. Non-staff users also couldn't submit edits to existing links or add text-based download links.
While a "correct song thread" will probably still exist in some form, with these and the ability for regular users to submit edit requests for artist and other pages, we may reduce the amount of things currently posted there as they will now be addressable in a more automatic fashion.
At the moment, songs that are a remix of two or more different songs (mashups) can only list one as their parent. If there's other things like this (similar to superartists), they should be fixed as well.
The edit forms for relationships like these would be best suited as a search box that automatically provides suggestions and fills in the ID for the user, rather than expecting them to know or have to look it up. Multi-select relationships can behave similarly, as having to scroll through the list of artists to select the ones you need for a newly uploaded song or incompletely attributed coop is currently a pain.
The current site had many implicit rules that were incompletely followed or followed differently by many staff. Some staff would defer dealing with certain things, such as song uploads, for fear of making a regrettable mistake due to some unwritten rule.
The new site should write down how things will be done, in a public and transparent way, so it is easier for staff to follow them and do so consistently. It also lets users and visitors know how the site operates. This may best be written as part of an FAQ page that staff can update rather than a bunch of paragraphs like typical "terms of service" pages.
FAQ entries should indicate when they were last updated and keep a history of all updates, even if this history is not visible to non-staff.
Edit logs for all objects, excluding FAQs and requests/reviews, should be visible to all users. This doesn't mean the entire context of an an approved request will be visible, but at least the date it was approved (or submitted) and the user who made the request (not who approved it) will be.
This has been debated many times, and both complicated and simple solutions have made people complain. This proposal hopes to balance both people's freedom to request what they want, with peoples desire not to always hear particular things often.
The rule is as follows:
A song will start with a two week (336 hour) lock time the first time it is requested. If it is requested again within 72 hours of unlocking, then 48 hours are added to the lock time. If it is requested greater than 72 hours after unlocking, the lock time will return to two weeks.
This means if a song is requested at noon on a Friday, and a user consistently requests it again as soon as it unlocks, nobody will be able to request it at noon on a Friday for 18 weeks.
This avoids locking songs based on rating and makes it so longer lock times are directly influenced by the users themselves. It doesn't stop people from requesting particular songs but helps encourage variety to avoid the same songs every other week at the same time. The 72 hours after unlocking is so that if users request it in the middle of the week they will be encouraged to wait until the weekend, and if they request it on a Friday will be encouraged to do it on a Monday instead.
It seems easy to implement as well, as it has no fancy rolling windows or vote-based adjustment multipliers. In Pseudo-Python:
# Assuming last request times are the number of seconds since the epoch
if song.requests[-1] + (song.lock_time + 72) * 3600 < now:
song.lock_time = 336;
else:
song.lock_time += 48;Any FAQ entry on this should just state how it works, in a non-technical way, without any opinions or commentary on it to avoid the idea that we're targeting any particular user or practice. This is not a suitable anti-crap session mechanism and it is not intended to be one.
As with the DJ Random section, the number parts of this could be made configurable so different instances would be allowed to change it up. Setting the lock time extension hours to zero would disable the above behavior.
Since you can't wish for more wishes, this is where the unlikely but fanciful ideas can go.
It seems somewhat reasonable that if some users are opposed to banning tunes and we cannot provide a download link for various reasons, that different streams should exist which cater to these sorts of things.
Is a tune tangentially Scene related but many people consider it to be a game tune? Is this song not well rated, but some people really enjoy hearing it? These tunes could become only available for request on certain streams so those who don't mind hearing them can tune into the stream where they're playable.
This means instead of a tune getting banned for being awful to many, it would be unable to be queued for the default stream but could be heard on a secondary one that doesn't filter by rating or tag. This would require quite the rethink of architecture, because the site would now have to support multiple queues in the UI and broadcast multiple sources. In practice this means it would probably be limited to two streams, one default, and one "everything" stream.
"Banned" tunes may still exist, as it's not impossible for a tune to later be found to have violated copyright or could otherwise cause the site trouble. However dealing with these would be more objective than past bannings.