- 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.
- Should be fairly limited in quantity (one person should only be subscribed to a few artists, to prevent being overwhelmed by edits)
- Note I am subscribed to 4k artists and never get overwhelmed by edits (I have less edits per day than a person only subscribed to JSB probably has). So how do you plan to measure this? --Reosarevok 10:07, 16 November 2011 (UTC)
- I’m not sure. I’m subscribed to 250 artists and probably could do alright with a lot more. Different people likely have different thresholds for being overwhelmed. I don’t even think this should be enforced though, I’m just suggesting that whatever the subscription system should try to keep people relatively tightly focused on the stuff they actually care about, rather than every artist they see. I for one am much happier to do real lookups and such work on stuff I care about and preferably own, than I am to have to manually ignore changes to a obscure releases that I don’t own and have no interest in. and it’s the latter category that makes me likely to get tired of voting and say “screw this, I’m entering some more data” —Hawke 18:44, 18 November 2011 (UTC)
- Everyone should be automatically (forcibly?) subscribed to every release in their collection. Possibly to the RG of every release in their collection.
- All open edits for any recording of the subscribed work, and release edits which affect that recording’s track.
- 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.