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]
