just messing about with ideas for a new edit schema
2010-11-30 33421, 2010
warp
yikes, the commented parts on gist.github are unreadable.
2010-11-30 33453, 2010
ocharles
heh
2010-11-30 33411, 2010
ijabz joined the channel
2010-11-30 33444, 2010
djce joined the channel
2010-11-30 33414, 2010
ijabz joined the channel
2010-11-30 33413, 2010
luks
ocharles: well, it seems like you are designing something from a technical point of view
2010-11-30 33425, 2010
luks
there are high-level issues with the edit system
2010-11-30 33411, 2010
ocharles
yes, i've tried to solve the high level issues that I'm aware of
2010-11-30 33414, 2010
ocharles
but i'm not a heavy editor
2010-11-30 33458, 2010
luks
then you should take the most complex use case, changing a release (including AR credits)
2010-11-30 33424, 2010
luks
if you fix how ARs are voted on, you fix at least 80% of all problems
2010-11-30 33458, 2010
ocharles
well i guess in this each AR change/addition/deletion is an edit, and they are all grouped together. a group is atomic - it either passes or fails
2010-11-30 33427, 2010
ocharles
if an editor doesn't like a certain change, they can let the original editor know, and they can revision certain edits. that would probably invalidate all votes and require a revote or something
2010-11-30 33455, 2010
ocharles
or, voting is done per edit so some of the group can pass and some can fail
2010-11-30 33403, 2010
ocharles
i dunno which works better
2010-11-30 33419, 2010
luks
I don't know
2010-11-30 33424, 2010
luks
I recently started to think that having generic ARs in MB was a mistake (from user perspective)
2010-11-30 33400, 2010
ocharles
and it would be better to have something more freeform?
2010-11-30 33403, 2010
ocharles
or less freeform?
2010-11-30 33407, 2010
luks
so if I were to redesign the edit system, I'd probably try to hide them (show them as "credits", "members", "urls", "...")
2010-11-30 33413, 2010
ocharles
yea, we're moving towards that
2010-11-30 33437, 2010
ocharles
the new relationship stuff will get rid of the "has/had" terminology and lend itself better to being integrated in other places
2010-11-30 33416, 2010
ocharles
showing band members in the side bar for example - going a step further editing an artist would show a set of "members" fields, if the type is a group. I guess this is the kind of thing you're thinking of
2010-11-30 33433, 2010
luks
yeah, but now we are talking about editing
2010-11-30 33404, 2010
luks
I'm not sure if makes sense to expose them as "ARs" while editing something
2010-11-30 33439, 2010
ocharles
I'm not exposing them as ARs during editing - see above, they would just show up as a set of text fields (autocomplete) to choose the member artists. maybe with founding checkboxes and begin/end dates
2010-11-30 33452, 2010
ocharles
but never mentioning them as ARs really, or letting the user choose the type here
2010-11-30 33412, 2010
ocharles
i dunno if you consider that still too much like ars=
2010-11-30 33445, 2010
luks
well, in the mockup you talk about object graphs
2010-11-30 33451, 2010
luks
I think that's one of the main problems
2010-11-30 33459, 2010
luks
and one of the main places where ARs show up
2010-11-30 33420, 2010
luks
I'd try to flatten everything in the edit system
2010-11-30 33449, 2010
ocharles
i'm not sure how that backend representation matters
2010-11-30 33452, 2010
luks
e.g. release would consist of all the mediums, tracklists, tracks, credits
2010-11-30 33400, 2010
luks
it does
2010-11-30 33409, 2010
luks
editing a graph is HARD
2010-11-30 33420, 2010
ocharles
no argument there, but I'm not suggesting graph editing really
2010-11-30 33438, 2010
luks
yeah, but that's what we do right now
2010-11-30 33450, 2010
luks
and the mockup doesn't seem to be changing that
2010-11-30 33459, 2010
ocharles
hm
2010-11-30 33427, 2010
luks
I'd take something as stupid as the discogs edit system as a reference
2010-11-30 33431, 2010
ocharles
Well no, I guess it doesn't - this is just simplifying how we store the data, and making sure everything is valid for historical
2010-11-30 33437, 2010
ocharles
purposes*
2010-11-30 33438, 2010
luks
you have edit artist, edit release, edit label
2010-11-30 33440, 2010
luks
nothing else
2010-11-30 33443, 2010
ocharles
right
2010-11-30 33423, 2010
luks
I believe it can be done in MB as well
2010-11-30 33431, 2010
luks
it will remove some flexibility
2010-11-30 33439, 2010
luks
but it would be much more usable
2010-11-30 33446, 2010
hawke_ joined the channel
2010-11-30 33450, 2010
ocharles
So what do you mean by flattening? You mean having less edits?
2010-11-30 33430, 2010
ocharles
The way I see this is: a group is like a transaction, an edit is like an operation.
2010-11-30 33459, 2010
ocharles
so you only enter what is effectively edit artist, create artist, edit release etc. but the implementation splits them apart, because that's easier for me to work with
2010-11-30 33403, 2010
ocharles
and operations are composable
2010-11-30 33432, 2010
luks
I don't see an easy way to combine them to see the end result
2010-11-30 33439, 2010
ocharles
the edit artist "group" is a composition of an edit artist edit, and maybe some changes to ar links
2010-11-30 33410, 2010
luks
but if I have *everything* about a release in a single edit, I can preview it, revert it, etc.
2010-11-30 33430, 2010
luks
I'd probably even consider the entities to be "wiki pages"
2010-11-30 33408, 2010
luks
it might look weird, but it seems to work more than fine for wikipedia
2010-11-30 33422, 2010
ocharles
ok, I see the argument here (and some of it is doable with split edits, some is not) - but now how are you going to handle voting?
2010-11-30 33423, 2010
luks
they have all kinds of structured metadata on a plain-text page
2010-11-30 33433, 2010
ocharles
because "edit release" is going to be huge
2010-11-30 33449, 2010
luks
is that a problem?
2010-11-30 33453, 2010
ocharles
wikipedia works because it doesn't have voting
2010-11-30 33455, 2010
luks
at least it's revertable
2010-11-30 33440, 2010
ocharles
The idea of edit revisions and large edits could work though
2010-11-30 33443, 2010
luks
and I think that if we have 2k edits instead of 30k edits, more edits would get voted on
2010-11-30 33448, 2010
luks
so they would pass faster
2010-11-30 33404, 2010
ocharles
So I insert one big edit release edit. someone has a problem with 1 tiny bit, I create a new revision of my edit and address that, and then the edit can pass
2010-11-30 33441, 2010
ocharles
does that sound sensible?
2010-11-30 33425, 2010
hawke_
Isn’t this a similar problem to content management’s “current approved version” vs. “draft version” things like what is done for http://musicbrainz.org/doc/ ?
2010-11-30 33430, 2010
luks
yes, probably, maybe, I don't know :)
2010-11-30 33442, 2010
luks
I've been thinking about MB editing a lot
2010-11-30 33443, 2010
ocharles
:)
2010-11-30 33450, 2010
luks
and I'm still not sure what's the best approach
2010-11-30 33456, 2010
luks
the problem is that there *is* an object graph
2010-11-30 33400, 2010
luks
there is no way around that
2010-11-30 33414, 2010
luks
it's a matter of drawing the line between entities
2010-11-30 33422, 2010
luks
I'm not sure where that line is
2010-11-30 33427, 2010
hawke_
If we’re just trying to get the outstanding edits count down, I think the first thing would be to shorten the time for edit approval on things of “normal” data qaulity.
2010-11-30 33431, 2010
hawke_
*quality. :-D
2010-11-30 33456, 2010
luks
it's more about "useful" edit system
2010-11-30 33409, 2010
luks
if you have 100 AR edits, it's not easy to vote on
2010-11-30 33420, 2010
luks
you either don't vote, or blindly vote yes on all of them
2010-11-30 33402, 2010
hawke_
Mostly “don’t vote”.
2010-11-30 33449, 2010
hawke_
That’s the other reason to shorten the vote time: so few people are likely to know or care about any given edit enough to vote on it.
2010-11-30 33437, 2010
hawke_
[that it makes the voting system almost useless as is]
we just need 3 fields: ARTIST (including all different names) + ARTIST_ID for searching, and storing ARTIST_CREDIT for output
2010-12-01 33501, 2010
ijabz
If you don't have a separate field for individual artists, and the complete artist credit for the album you cannot do exact matches properly because you dont know what the artist is for the album
2010-12-01 33548, 2010
ijabz
They are necessary thats why we put them in, and I don't see any advantage in removing size, (index creation time and index time will be affect will be neglible)
and "artist", "artistname" and "creditname" are not really clear
2010-12-01 33552, 2010
murdos_
there's a point where, if you want exact matches properly, you'd better use a database
2010-12-01 33554, 2010
ijabz
artist credits ARE confusing :)
2010-12-01 33536, 2010
ijabz
but the thoase releases a re credited to renaud not renaud3 so why should renaud3 return matches for the default artist field
2010-12-01 33509, 2010
murdos_
but we can perfectly hide this complexity in the search server
2010-12-01 33519, 2010
murdos_
ijabz: renaud == renaud3
2010-12-01 33527, 2010
ijabz
Yes but one is an alias or somthing
2010-12-01 33504, 2010
murdos_
no, "renaud3" is the actual artist name, "renaud" is the specific credit name used for recordings
2010-12-01 33558, 2010
ijabz
You can hide the complexity in the user interface, if you want to search both you just search both fields, once you merge into one field youve lost that information
sorry, I've to go, but I hope we can clear this issue later
2010-12-01 33504, 2010
ijabz
phew, I also need to get on with someting else
2010-12-01 33518, 2010
dinog joined the channel
2010-12-01 33552, 2010
kurtjx joined the channel
2010-12-01 33501, 2010
ocharles
warp: I might have to lump a bit of JavaScript work on you
2010-12-01 33518, 2010
ocharles
I've done the work to create new artists and labels, and for the most part it works - but the display is kinda messed up :)
2010-12-01 33513, 2010
ocharles
At the moment it creates artists if you leave the artist field blank and add a artist credit name. we should probably have an option in the drop down called "add new artist" which fills in the artist credit name and does something special to the artist selection box (maybe italic text saying create new artist or something)
2010-12-01 33551, 2010
kurtjx joined the channel
2010-12-01 33557, 2010
murdos_ joined the channel
2010-12-01 33545, 2010
ijabz
murdos_I thought about your example some more, it is very contrived, I think in reality if you were to change the artist name you might expect the credit names to also change and that is the problem.
2010-12-01 33507, 2010
ijabz
Where the artist name and credit name differ it will be important in some cirumstances to search for these individually
