- No-one votes.
- Edits generally take two weeks, and pass with no-one looking at them.
- Subscription management is a pain in the ass, and of limited use.
- Status quo is king: It is easier to stop an edit than it is to make one in the first place.
We have auto-editors so that trivial, obvious changes can be made immediately, without the two week delay.
Unfortunately, this is too much power to give to a few people: Everyone should have the ability to make obvious, trivial corrections, and they should appear quickly in the system. Everyone should also have their edits reviewed, preferably by someone with relevant knowledge.
So instead we should look to a self-selected set of subject matter experts, people with an interest in a given area. Fortunately we already have such a system: Subscriptions.
But the subscription system sucks. It is limited in scope (you can only subscribe to a few entities: Artists, labels, and editors). Even if you do try to use it, you tend to get a lot of extraneous crap (do you really care about every edit to a compilation that an artist you’re subscribed to happened to also be on?)
Subscribers should only be notified of things that they need to (or should) take action on. So, “applied edits” should never be relevant, or possibly never exist — they’re in the past, and the only thing to be done if they were wrong is to revert them. Also, subscribers should ideally be notified of edits that are likely to affect them (in tagging, for example)
In order to make sure that the subscription actions are relevant, subscriptions should be broadened to more entities:
- Direct changes to the artist. (start/end dates, country, sortname, merges, etc.)
- Changes to any release where the artist is the Release Artist
- Changes to any track where the artist is the Artist Credit for the track, or for the recording
- Changes to any ARs of the artist.
- Any change that could impact the release:
- Direct changes to the release (name, release date, label, etc) or its tracklist (track name, artist, etc.)
- Changes to any AR involving a recording on the release
- Direct changes to any Artist credited for the release, release group, or any track or recording on the release
- Everyone should be automatically (forcibly?) subscribed to every release in their collection. Possibly to the RG of every release in their collection.
- Direct changes to the work
- Changes to any AR connected to the work
- Changes to any other entity of an AR connected to the work.
- Any changes which affect a track to which a related recording is connected.
- Obviously? All releases connected to the label.
Drop voting as it exists now. Replace with approval:
Entities have two views: “as it is now” and “as it may be”.
Users are shown the “as it is now” by default, with an indication that there are pending edits (similar to the current yellow highlight)
If desired, a user should be able to go from viewing an entity which has edits pending, to a view which shows the entity “as it may be” [after edits have been applied]. This view should have some way of showing exactly what has been changed, similar to common wiki or trac red/green/yellow diff view.
From the “as it may be” view, the user should be able to indicate their approval of it.
Once a user has approved a view, that entity should appear to that user as the new view in all cases: web, lookup results, etc.
When a user is looking at the “as it may be” view, they should see the most recent change, but should also be presented with some indication that there are other alternate views.
Once some threshold of subscribers have approved a view, that view should become the new default, and the cycle repeats.
By not approving the new view, the user has effectively voted for the status quo.
If they like it but see some additional change that is missing, the “as it may be” view should be editable. (allowing user to choose either version as a base for editing — simple reversion!)
Alice changes the name of the fourth Led Zeppelin album to [untitled]. The main view now looks like this (to logged-in users):
The “as it may be” view looks like this:
For the sake of argument, we will say that 5 people are subscribed to this artist. In order for this change to be applied, 3 of those people will need to approve the new version. Two approve it. The view remains as above. Then Bob, one of these subscribers, does a little more research into the situation and thinks that the title would be better as Zoso. He enters a change to that effect.
The main view still looks like this:
While the “as it may be” view now looks like this:
Other users looking at this view should made aware of both Alice and Bob’s views, so that they can approve either. Alice should see her own view by default, and also be made aware of Bob’s view. (A link to the effect of “2 new variants available!” would work)
Finally, Carol (another subscriber) thinks it would be a good idea to combine the two options. She enters an edit to change the title to [Zoso]. Two others agree, and this view becomes the default. The “as it is” view looks like this:
Non-logged-in users (and data feeds?) do not ever see the highlight for pending changes, and only see it change from Led Zeppelin IV to [Zoso]. Bob continues to see his preferred Zoso until he changes his approved view to something else.
Approval of a view must only apply to that entity directly, but edits should show up for items linked/related to that entity. An “add release” edit would be an approval of that release, not of the artist. A change to a recording would show up on a related work’s “as it may be” view, but would have to be approved at the recording level.
Is there a sane way to resolve/apply/show larger approvals/edits to multiple entities? Finer-grained approval of part of an edit, i.e. approve a specific “add release” edit from the artist’s release list without having to go to the release, and without approving all pending changes to an artist?
- 1 person can become the “god” of a release or artist etc. easily, by being the sole subscriber.
- artist merges might become complicated. (1 person enters new bogus artist, enters in bogus or crap data — or worse, a mixture of good and crap data), tries to merge with good artist; what happens?
- too many subscribers could cause an entity to stagnate.