Difference between revisions of "User:Hawke/Proposal/Editing system"

From MusicBrainz Wiki
Jump to navigationJump to search
Line 8: Line 8:
 
; Artist: Should be fairly limited in quantity (one person should only be subscribed to a few artists, to prevent being overwhelmed by edits)
 
; Artist: 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? --[[User:Reosarevok|Reosarevok]] 10:07, 16 November 2011 (UTC)
 
* 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? --[[User:Reosarevok|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” —[[User:Hawke|Hawke]] 18:44, 18 November 2011 (UTC)
 
; Release: Everyone should be automatically (forcibly?) subscribed to every release in their collection. Possibly to the RG of every release in their collection.
 
; Release: Everyone should be automatically (forcibly?) subscribed to every release in their collection. Possibly to the RG of every release in their collection.
 
; Work: All open edits for any recording of the subscribed work, and release edits which affect that recording’s track.
 
; Work: All open edits for any recording of the subscribed work, and release edits which affect that recording’s track.

Revision as of 18:44, 18 November 2011

Problems

  • 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.

Solution

Fix subscriptions

Artist
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)
Release
Everyone should be automatically (forcibly?) subscribed to every release in their collection. Possibly to the RG of every release in their collection.
Work
All open edits for any recording of the subscribed work, and release edits which affect that recording’s track.
Label
Obviously? All releases connected to the label.

Fix voting

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.

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!)

Complications

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?

Results

  • 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.