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

From MusicBrainz Wiki
Jump to navigationJump to search
Line 5: Line 5:
   
 
==Solution==
 
==Solution==
Fix subscriptions:
+
===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)
 
; 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)
Line 11: Line 11:
 
; 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.
 
; Label: Obviously? All releases connected to the label.
 
; Label: Obviously? All releases connected to the label.
  +
  +
===Fix voting===
   
 
Drop voting as it exists now. Replace with approval:
 
Drop voting as it exists now. Replace with approval:
Line 30: Line 32:
 
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!)
 
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===
+
==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.
 
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.
   

Revision as of 18:25, 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)
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.