Nabble - MusicBrainz - Experts

CALL for Visiting position for Indian researchers on Semantic Multimedia

2007-02-28T02:43:25Z

--- Apologize if you receive multiple copies ---

Greetings,

thanks to Italia/India agreements, SeMedia
(http://semedia.deit.univpm.it) and A3LAB (http://a3lab.deit.univpm.it),
two research groups within UNIVPM (Universita' Politecnica delle Marche)
and leaded by Prof. Francesco Piazza, are now looking for one or more
researchers from Indian academic institutions (Ph.d students also ok)
interested in a 12 month visiting period.

Topics of the research will be Multimedia Semantic processing.

By this we mean a cross disciplinary study which employees computational
intelligence and digital signal processing algorithms on one side and
High Level Metadata (from Mpeg-7 to RDF and Ontologies) on the other.
We will consider candidates strong in either subject as long as highly
motivated into pursuing a research across the two.
The net salary will be 15000 euro, covering the entire duration of the
stay.

The deadline is near so we encourage interested candidates to contact us
as soon as possible for further information.

Christian Morbidoni c.morbidoni@...
<mailto:c.morbidoni@...>
Stefano Squartini sts@... <mailto:sts@...>

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

libtunepimp python write wma

2007-02-25T04:22:28Z

Hi,
I read that tunepimp has the ability to write wma metadata. I have tried
to figure out to write this with picard, but i seem to get no luck. The
thing i basically do is (in Python):
tp = tunepimp.Tunepimp()
tp.addFile(path, 1)
id = self.tp.getFileIds()[0]
tr = self.tp.getTrack(id)
tp.lock()
md = tr.getLocalMetadata()
tp.unlock()
md.artist = "Nodoboy"
tp.lock()
tr.setLocalMetadata(md)
tp.unlock()
tp.ReleaseTrack(tr)
tp.writeTags([id])

The tag doesnt change. Only when i do tr.setStatus(tunepimp.eVerified)
before setLocalMetadata, it just wipes the track.
Maybe someone can provide me a example how to set this up right.
Greetings,
Mark Baas

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Edit cancelled long after it succeeded

2006-11-16T12:52:03Z

Please send this message to mb-users.

mb-experts is factually defunct since it currently serves no real purpose.

DonRedman

On Thu, 16 Nov 2006 16:39:37 +0100, Matt Perry wrote:

> A long time ago I made this edit which succeeded:
> http://musicbrainz.org/show/edit/?editid=4235152
>
> I know it was approved. I remember it passing the vote, the change
> being made, and later I tagged my album with that data. Now in
> reviewing the edits I see that the edit is marked as cancelled. How,
> and why, was this edit's history changed? Why is it marked cancelled
> when it never was cancelled?
>

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Edit cancelled long after it succeeded

2006-11-16T07:39:37Z

A long time ago I made this edit which succeeded:
http://musicbrainz.org/show/edit/?editid=4235152

I know it was approved. I remember it passing the vote, the change
being made, and later I tagged my album with that data. Now in
reviewing the edits I see that the edit is marked as cancelled. How,
and why, was this edit's history changed? Why is it marked cancelled
when it never was cancelled?

--
Matt Perry | matt at primefactor dot com

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

More Specific/New Release Attribute for Soundtracks/Musicals

2006-10-22T04:05:11Z

Okay, first things first. I'm not sure if I should be
posting this in the expert forum. Maybe this falls
under style, or maybe this falls under something else.
Please let me know so I will better direct this kind
of idea in the future, thank you. Also, please forgive
me if this subject has already been discussed and
agreed upon. I wish the archives were easier to
search. Hopefully, if nothing else, this will be a
new look at an existing issue. Finally, thanks to all
who read this and give it thought, even if you don't
agree.

The idea is fairly simple, but it may have deeper
implications. Essentially, I think it would be smart
if the musicbrainz database had a special category for
soundtracks/live musicals/scores. This would make
sense for a few reasons. 1) It can get confusing when
searching MB for a soundtrack/score and running into
the other 2)it gets even more confusing when searching
for the soundtrack for a musical and not knowing if
the results are a specific live performance or the
soundtrack for the film version. 3)It adds yet more
issues when the question of how to list the
artist/performing artist for the album/song. Do we
want to list the performer of a song if it is an actor
who otherwise is not a musician for the sake of them
having one entry? epsecially if this actor a)shares
the name of another musician or b)sings duets with
other actors on the soundtrack, thus creating multiple
listings of artists that all lead to this one album?

I hope that made sense, and with that hope, let me
move on...

1) The issue of a live (let's say broadway)
performance of a musical, could be seen as a style
issue that is already solved with the style guidline
on how to enter classical/operatic perfomances into
the database, specifcally where the album would be
listed under the composer of the music (let's say
leonard bernstein) and the title of the album would
be, for example "West Side Story" with accurate info
on the production company and primary performers.
While this would resolve the issue of multiple
performances showing up in a search, it would not help
any of the issues with movie soundtracks and it would
still leave out information on who is performing each
song. Also, as a quick aside, it leaves out which
character is singing. I bring this up only as an
aside, as it could be resolved by adding the
characters' names as a parenthetical after the title
of the track. I think this should be seriously
considered as a style guidline for showtunes, but I
digress...

2) Most people, when they think of soundtracks, think
of a collection of songs that were played during the
film that have been released by the studio to
accompany the movie. Soundtracks like "The Big
Chill", "Batman Forever", or "The Big Lebowski" are
great examples of soundtracks like this. They usually
are a mix of artists and already existing songs (or
made for the film, but stand on their own). I collect
soundtracks like these because they give me the mood
of the film while at the same time give me a variety
of songs without getting a cheesy "Time Life
Presents:" style mix tape. (Quick aside, I also like
to put together my own mix of "unauthorized and
complete soundtracks" for films, but as we all know,
that's verboten on MB.) These types of soundtracks
easily fit into MB's "Various Artists" category, under
soundtrack. However, music scores and soundtracks for
musicals are not so simple. Within this paragraph,
I've pointed out 3 types of albums that could be
considered "soundtracks", and on top of that, there is
a fourth: the single artist soundtrack. For those
that don't know what this refers to, some films have
only one artist make the entire soundtrack. This
would not be considered a "score" usually, as the
songs usually have lyrics and are arranged more like
the standard 3-4 minute song for the radio rather than
long classical-like compositions. To add to this
whole mess, some soundtracks like this have multiple
artists per track, but are considered to be the work
of the primary artist. Getting to the point... Each of
these types of soundtrack are unique and it seems to
me that they each present individual issues for style:
1) Standard Soundtrack: Most Simple, Typically Various
Artists, with artists that usually have other albums
or appear on other albums.
2) Score: More like a classical work, where the
composer/arranger should be considered the artist, and
any symphony or band listed after the album title.
3)Musical: Could be dealt with similar to "classical"
but either at the cost of leaving out track details or
adding artists to each track that creates a mess. Also
easily confused with stage versions of production.
4)Single Artist Soundtrack: Fairly simple, since
guest artists can be listed for each track, but
confusing as far as whether it is more of an "Album"
by the artist or a "soundtrack".

It can also, it should be noted, be confusing to MB
users with various organization systems where to file
their music. I put all of my soundtracks under
"Various Artists", including scores. But if the
soundtrack is a single artist and the soundtrack is
more of an example of the artist than the film, I keep
the album with the artist. But what about stage
versions? Should these be kept in their own folder,
with movie soundtracks? with the composer of the
film? In the end, this is a personal decison and
doesn't stop the earth on its axis, but anything MB
can do to make these types of albums more distinct as
well as making sure all relevant details are included
helps the MB users and keeps the database easier to
search and crossrefrence... In a nutshell, a musical,
even one that is filmed, is not really the same as the
"soundtrack" for a film, thus it should really be
grouped with other musicals rather than soundtracks.
Ideally, Various Artist Soundtracks, Musicals, and
Single Artist (or band) Soundtracks should be grouped
accordingly and not all mixed together.

Okay, I'm sorry if that was way too much build up, but
here is the most basic version of my idea...once again
thank you to those who are reading this and understand
why these are important issues for the MB project...

So, my suggestion for these issues is this:
1) Create a new category (or subcategory) for
musicals. The primary category would be "musical",
the sub categories would be "Film/Cinema/Movie" and
"Stage/Live". The artists would always be listed as
the composer and thus the album would be listed under
that artist's name, and the stage information most
relevant would be listed in the title of the album.
Thus, if someone went to "Leonard Bernstien", they
would scroll down to the "musicals" category and
easily see the film versions as well as the stage
versions and see from the titles which ones were
which. It should also be pointed out, quickly, that
if a song by leonard bernstien is used in a film that
he didn't compose the music for, at this point that
film's soundtrack shows up under "soundtracks", which,
given the current system, makes this random soundtrack
and the musicals he composed grouped together.
Another reason why a new category should be released
is because sometimes a broadway company will record
songs from a show in a studio for commercial release.
Is this a soundtrack or is it live? or it an album?

Basically, if musicals, both film and stage, had their
own category, this would separate them from the other
types of soundtracks and make it clearer when
searching for an artist or an album what the nature of
the "soundtrack" is.

2) My second suggestion deals with the issue of the
track artist.
Right up front, I want to again suggest that the style
council strongly encourage in its guidlines that
characters (or groups of characters) be included in
the track name. This adds more information to the
database and to the user as well as making users files
more detailed and fun (simple example: The song
"Officer Krupke" is sung by "The Jets" in West Side
Story, and having that in the title both adds to
listening to it and helps the listener better versed
when discussing the song to others).
As far as musicals and adding artists go: Whether it
a film or musical, it seems that if a song is done by
a large group or the entire cast, the artist should
not be adapted and left as the primary artist. The
thought of leonard bernstein singing all of the parts
of "America" is silly, but a fair trade for keeping
things simple. Another consideration is to have the
artist listed as "Cast". This touches on another
issue in MB, where generica artist titles like
"unknown" get grouped into one big blob. But such a
placeholder could work, if the community perffered it,
like "[cast]".
As far as indidual artists go, it seems reasonable to
list the solo artists for a solo performance. If,
when looking at film musicals, the actor did their own
singing, they deserve to be listed. However if
someone else did the singing, that person deserves a
credit and shouldn't be overlooked by MB as they have
probably been everywhere else.
As far as duets and groups go, this issue is larger
and my solution is not as easy as the others. I have
suggested it elsewhere but never saw it come to light.
Here it is, as simple as i can make it:
1)when a new artist needs to be added, if the artist
is a one-time or one-album pairing of two artists,
this should be designated when the artist is added.
This would mean that a new category like "one time
collaboration" or "One-Album Collaboration" category
would appear, in addition to "person" and "group".
This new artist would then have that information
attatched and any neccessary relationships could be
automatically generated from that category.
2)Going with the above suggestion, if this "one time
collaboration" category were created, it could even be
more broad, something like "collaboration" could be
the category. The idea would be that, if this
category were chosen, MB would generate fields for two
artists, and any other relevant detail fields, and
give the option of adding more artists than just two.
The user adding the artist would enter each artist
into a separate field and MB would check to see if any
of the artists were already in the DB. If they are,
it pulls that info, if they aren't, it asks the user
to add that individual artist. This would help for
musicals where different actors pair off for differnt
songs but MB doesn't need an artist listing for each
of these pairings and also help with the larger issue
of when, say, Dean Martin and Frank Sinatra do a duet
together, but haven't done a full album together or
perhaps did a "Rat Pack" album, but did one song on
the album as a duet..etc etc.

Okay, so thanks again for the consideration. I hope
this all made sense and stayed more or less close to a
relevant and useful idea, rather than my ramblings.
What it comes down to is assuring that those users of
MB who have a specific interest in musicals, both in
stage and film form, get the proper style and database
entrys, as well as detailed information on albums and
songs, that they deserve. The same attention that is
necessary for the many recordings of classical works
should be given to this category of music, and it
should not just be spread out over other categories.

Thanks

T

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Feature "ratification" process

2006-08-08T08:54:40Z

Don Redman wrote:
> Just a meta-note: I feel we are close to getting divided in camps again,
> which is stupid, since we try to solve the same problem.

I don't feel that at all, IMHO we are having objective and productive talk at the moment, better than ever. :)

If Nikki and I share the same opinions then it's either because we are actually a bit similar minded or because we are talking a lot - so when we express our opinions in public for the first time, we very often already had talked about the topic and exchanged our ideas - so of course what we say can sound very coherent.

Simon (Shepard)

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Feature "ratification" process

2006-08-08T08:35:13Z

Stefan Kestenholz wrote:
> I'm glad you try hard not to put the blame on anyone, the following
> observations i will put forward are neither such an attempt. Please
> keep that in mind :-)

And I hope that you didn't think the initial post of this thread was criticism of the way you work. Because I didn't intend to put blame on anyone either. ;) I just think the problem lays in the current processes which are noone's fault.

>> How can he suggest changes to the way developers' ideas are implemented
>> without being a developer?
>
> DonRedman can answer this question much better than i could...

And from how I understood him so far I guess I know how he would answer it:

If everything would have gone the "right" way (or: a better way), then you wouldn't have worked on the last server release alone in the first place but together with a handful of people from the community and then we would have had good communication during the development process, opinions from different people, a more satisfactory end result and less complaints afterwards.

This is an ideal we can try to reach but it still doesn't take one fact into account: as I said, the developers are the most inventive force in MB. And while the developer can always have productive talk with others about certain details (like we had last evening about the edit data display), that doesn't mean the developer will only do work when people ask for it. Instead the developer will steadily produce output to improve small details of the server, partly just small fixes and Feinschliff (missing a translation for it), partly adding new features. Yes, we as the community can try to be less lazy and work together with the developer on distinct parts (I will try to!), but we are surely not supposed to be the developer's nanny and read through all changelogs (which would be silly anyways). So yes, trac is open but it's too much data to be observed by everyone. And therefore of course it happens that improvements and new features land on the test server without anyone but
the developer being involved - and then eventually they land on the main server without anyone being involved because noone noticed it on test. That's a fact which IdeaChamponing still can't change. This doesn't necessarily have to be bad (it means progress in the development) nor can it be seen as anyones fault but you may understand that as a community member one sometimes feels a bit helpless about this because upon noticing such a change (where noone but the developer was involved yet) and in case you don't like it, you somehow have to try to start communication about it - *afterwards*.

A very simple example for that: Nikki talked about the collapsing of the releases. There is a little JavaScript feature that, when you collapsed the release, after leaving the mouse over the release header for a short while, will uncollapse it again. Given that I don't like that (1. because when I closed it I don't want it to uncollapse again unless I click the arrow again, 2. it makes copying the release title very hard), how should I proceed?
* I could enter a ticket for removing this feature. I think this is the worst possible solution.
* I could talk to Stefan about it, explain my reasons to him and he could say something like "Ok, I don't feel too strong about that, let's remove it" or "No, I want it to stay for that and that reason" or "Ok, I understand your concerns, but for that and that reason I think we still need it, though we could alter it in that and that way". I'm not sure if there's anything to alter about this apart from just removing it again, but there could possibly be. ;)
* What should I do though when I want to know how others feel about it? Note that this can come after talking to Stefan. Either because he said "no, it should stay for that and that reason" and I want to know how many others also don't like it, or because he said "yes, let's remove it" and I want to make sure, noone will miss it afterwards, or because he said "let's alter it in that and that way" and I want to find out if others think that'll be better (ok, this is what the test server is for). Since there's no ticket about this yet and no thread, there's no audience. So I have to create one. I could write an email (to mb-users?) titled "Issues with the JavaScript feature for expanding the release after a mouseover". It would feel a bit silly but perhaps it would work. But I think if everyone would do that with every concern they have, mb-users would be swamped. So I just don't know if that's a good idea.

Simon (Shepard)

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Feature "ratification" process

2006-08-08T08:24:28Z

Just a meta-note: I feel we are close to getting divided in camps again,
which is stupid, since we try to solve the same problem.

On Tue, 08 Aug 2006 13:53:35 +0200, Nikki wrote:

>> However, with a *feature* you rarely know beforehand how it will look
>> like, in what it will help and how it will create new problems. So if a
>> dev writes a ticket for a new feature (and this _is_ a burden: She[1]
>> might just have a vague idea but is forced to write up a comprehensive
>> proposal) the cummunity might at best make a very uninformed decision
>> about a feature that would look completey different if it were
>> developed.
>> If you have ever accompanied a development process, then you know that
>> it
>> is _during_ that process that understanding of the issue emerges, that
>> concepts are overthrown and problems solved. Not beforehand.
>
> The problem here is that features are getting thought up, developed and
> added without any input from the community at all. By the time we first
> find out about something, the developer has generally put a lot of work
> into it.

Yes, I agree very much that this is a problem. However I said (in the
paragraph above), that according ot my own experience noone can explain a
feature in detail before they have put work into it. Therefore any process
which decides *beforehand* will not work. That is why I proposed a process
in which input from and communication with the community are fostered
*during* the work process.

> There's often no "hey, I had this idea and made a mock up" or any chance
> for people to be the person acting as a go-between for the users and the
> dev. There's no place for the developer to collect opinions about the
> feature. I'll take the collapsing releases feature from the last server
> release as an example.

I think we all agree that that the way development went with the last
server release was not good. But mock-ups and gathering oppinons are
common in MusicBrainz. See the IntuitivePicardInterface and perhaps even
TaggerScript for current examples.

The point I want to get through is: Why reinvent the wheel? Look at cases
of good development in MB's hisotry and pick up what is good. Don't devise
a (IMHO overengineered) QA-process.

> It was thought up by Stefan, I presume, coded and
> put on the server. I tested the server, came across it and found it very
> irritating and had a couple of concerns. When I tried to explain my
> concerns to Stefan, we didn't get anywhere and the result was that Stefan
> was annoyed with me and I was annoyed with him (please notice that I'm
> trying to avoid placing the blame on anyone here).

If you put it this way, i would say: What went wrong was that the
communication between some users and the dev was shitty. Therefore the
right question would be: How can we enhance this communication. I believe
"IdeaChampions" are one, but surely not the only way. I just do not
believe that formalized processes (make a mock-up, put it to a vote) can
replace real communication. At least not in a development process, for the
reasons I already explained.

> I don't like the use of 'champion' because without looking it up in a
> dictionary, the only meaning of the word that I'm sure about is "someone
> who wins something", which isn't what's meant.

Robert invented the word. What else would you call that? A self-appointed
feature coach? A communicaton manager for an idea (I _hate_ the term
"manager")?

> What about when the *dev* has the idea? You've explained how the
> "IdeaChampion" thing works for *users* who have the idea, but haven't
> explained how we can improve the communication and process when the *dev*
> has the idea. I think that's -- without trying to place the blame on
> anyone -- where a lot of the problems in the last server release came
> from. Ideas being implemented without anywhere for the users to give
> their opinions.

You gave the answer yourself: Offer the users a way to give their
oppinions.
Now, since the dev is a volunteer you cannot give the users such an
opportunity which raises barriers to the dev (i.e. descirbe it in detail
and put it to a vote). The dev will simply stop coding for MB.
But you can go to the dev and tell her "Hey you are working on this
project, and I feat the community is not involved enough, I would like to
help you with that and be your 'secretary' towards the community". This is
an offer of help. Now, you are a voluteer too, so you should have some
interest in the featrue, too.

The point is that Keschte *has* asked for such assitance (not very
explicitly, though) but the request went unheard or unanswered. Finally
with the resturcturing of the MB server, it is likely that more of these
dev-initialted changes will happen in the future. But I am sure that
Keschte has learned to *insist* on early feedback the next time. And BTW
AR was not my idea, I still championned it.

> With general threads about
> features, there's more likely to be *general* feedback along the lines of
> "I like it!" and not just complaints.

I did not get that. What are you proposing?

>> I can only repeat: Pick up an idea or feature, push it through as *you*
>> think it should work. When you have succeeded, come back and propose a
>> policy based upon your concrete experience: Rules based upon practice.
>> If
>> this turns out to be an alternative/better/second way compared to
>> IdeaChampioning, then I will be most happy with the result.
>
> How can he suggest changes to the way developers' ideas are implemented
> without being a developer?

Am I a dev? I have coded a bit of OO Pascal in school, that's it.
IMO it actually _helps_ not to be a dev. Just pick a dev you go along with
well and offer them help. The important thing is that you are not helping
with the coding. You are helping with the *communication*:
- by being the contact person for the community (keep noise off the dev's
shoulders),
- by translating aggressive feedback into positive feedback,
- by documenting the evolving development process
- by educating the community
- by putting things to an informal (apache-style) vote on the mailing
list, if you want,
etc. etc.

And there is another thing which you have already done in your mail: Point
out to the things that went wrong the last time in a neutral, observing,
and constructive way. This helps a lot to avoid the same mistakes the next
time. Actually *that* would be worth being compiled on a wiki page right
now. ThingsThatCanGoWrongInTheDevelopmentProcess, or the like. I am sure,
there must be an even longer name. ;-)

DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Feature "ratification" process

2006-08-08T06:24:40Z

I'm glad you try hard not to put the blame on anyone, the following
observations i will put forward are neither such an attempt. Please
keep that in mind :-)

> The problem here is that features are getting thought up, developed and
> added without any input from the community at all. By the time we first
> find out about something, the developer has generally put a lot of work
> into it.

i remember very well how things went during the last server release;
work was started, lukas and nikki participated a bit, and suddenly i
was alone. its not true at all that features are developed in MB
without user interaction -- IMO its quite the opposite. DonRedman is
right in his assessment of the situation -- if we can get the
community to involve themselves more, and stick to their commitment --
this is the part which requires communication skills and persistence
-- then we'll have a more satisfactory experience for all parties
involved. We do not need any more tools for that, those who care find
the ways to get in touch with the developers, and the tickets on trac
are publicly accessible, i think this is enough. Most users probably
don't even care, until they see it working the first time.

> put on the server. I tested the server, came across it and found it very
> irritating and had a couple of concerns. When I tried to explain my
> concerns to Stefan, we didn't get anywhere and the result was that Stefan
> was annoyed with me and I was annoyed with him (please notice that I'm
> trying to avoid placing the blame on anyone here).

Yes, this is the experienced vs. inexperienced users problem. The idea
behind the collapseable items is to try not showing all information at
once for the users who are confronted the first time with it. If
things would have happened differently, we might have figured out
before the release when the collapsing makes sense and when it
wouldn't. Most changes had been mentioned in the blog post, and the
testing was running for a fair amount of time.
Its exceptionally hard to find the balance when changing and
(hopefully) improving aspects on the site, because there are always
users who think that all was quite fine how it was before, but:
Even the main site should be allowed some slack to try new things
out, but some people reacted to the new release like it was the end of
all things as we knew them. There will always be issues that need
fixing, or improvement, but the reactions to some things changed were
undue, IMHO. Picard for instance is still in a pre 1.0 state, and lots
of people use and like it, even if there are some issues that can be
annoying.

> How can he suggest changes to the way developers' ideas are implemented
> without being a developer?

DonRedman can answer this question much better than i could...

I hope i have hit the mark i attempted to hit when I started this
mail. After proof-reading it i feel its not too bad. Let the feedback
be heard :-)

--keschte

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Feature "ratification" process

2006-08-08T05:53:35Z

On Tue, Aug 08, 2006 at 11:46:20AM +0200, Don Redman wrote:
> Some issue trackers give users the possibility to vote _for_ a ticket.
> (but not against). This is a means of measuring the percieved importance
> of an issue to the community. People can rate how annoying a bug is to
> them. This works. I do not know if Trac supports this. It is really only
> necessary in very large projects in which the devs loose the overview over
> all the tickets.

That still doesn't really solve anything, the people who don't consider it
a bug or don't like the RFE are left out. If a dev fixes/implements it,
we've got exactly the same problem.

> However, with a *feature* you rarely know beforehand how it will look
> like, in what it will help and how it will create new problems. So if a
> dev writes a ticket for a new feature (and this _is_ a burden: She[1]
> might just have a vague idea but is forced to write up a comprehensive
> proposal) the cummunity might at best make a very uninformed decision
> about a feature that would look completey different if it were developed.
> If you have ever accompanied a development process, then you know that it
> is _during_ that process that understanding of the issue emerges, that
> concepts are overthrown and problems solved. Not beforehand.

The problem here is that features are getting thought up, developed and
added without any input from the community at all. By the time we first
find out about something, the developer has generally put a lot of work
into it.

There's often no "hey, I had this idea and made a mock up" or any chance
for people to be the person acting as a go-between for the users and the
dev. There's no place for the developer to collect opinions about the
feature. I'll take the collapsing releases feature from the last server
release as an example. It was thought up by Stefan, I presume, coded and
put on the server. I tested the server, came across it and found it very
irritating and had a couple of concerns. When I tried to explain my
concerns to Stefan, we didn't get anywhere and the result was that Stefan
was annoyed with me and I was annoyed with him (please notice that I'm
trying to avoid placing the blame on anyone here).

Instead of having one place to collect all concerns/problems/etc., people
are emailing the devs, bugging them on IRC, leaving bug reports on trac and
posting on the mailing lists. Surely *that* creates more work and stress
for the developers than, say, creating a thread on the mailing list and
pointing everyone to it if they start bringing the issue up elsewhere.

> IdeaChampioning is a concept that fosters communication _during_ the
> development process. From your mail I gather that you have not understood
> how it works (you are not to blame, as, ideed, it has not been documented).

I don't like the use of 'champion' because without looking it up in a
dictionary, the only meaning of the word that I'm sure about is "someone
who wins something", which isn't what's meant.

> No, it's not. It is not a one way process. IdeaChampioning also means to
> champion your idea in the mailing lists in front of other _users_.
> You will put it forward when peoploe point ot an issue that you think
> would be solved by the idea (this will help you to understand other user's
> views of the problems, to find flwas in your idea or imagined
> implementation).
> You will also have to 'shield' the dev from all the debates (and noise)
> that take her attention from the thing only she can do: coding. You will
> deal with the debates and give her condensed reports by mail, skype or
> wiki pages (which will instantly document your feature).

What about when the *dev* has the idea? You've explained how the
"IdeaChampion" thing works for *users* who have the idea, but haven't
explained how we can improve the communication and process when the *dev*
has the idea. I think that's -- without trying to place the blame on anyone
-- where a lot of the problems in the last server release came from. Ideas
being implemented without anywhere for the users to give their opinions.
Thus, the only real feedback generated was from people wanting things
changed which must be tiring for the dev. With general threads about
features, there's more likely to be *general* feedback along the lines of
"I like it!" and not just complaints.

> I can only repeat: Pick up an idea or feature, push it through as *you*
> think it should work. When you have succeeded, come back and propose a
> policy based upon your concrete experience: Rules based upon practice. If
> this turns out to be an alternative/better/second way compared to
> IdeaChampioning, then I will be most happy with the result.

How can he suggest changes to the way developers' ideas are implemented
without being a developer?

--Nikki

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Feature "ratification" process

2006-08-08T03:46:20Z

I think I see where we misunderstood each other. I am not against more
communication before and durnig the development process. I am, however,
opposed to two details in the *way* you want to achieve this:

(a) A voting mechanism that creates a hurdle, instead of a process which
fosters collaboration.
(b) Devising an abstract process as 'policy', instead of doing something
and leading to a policy by example.

I'll go through both points in detail.

Ad (a)
Some issue trackers give users the possibility to vote _for_ a ticket.
(but not against). This is a means of measuring the percieved importance
of an issue to the community. People can rate how annoying a bug is to
them. This works. I do not know if Trac supports this. It is really only
necessary in very large projects in which the devs loose the overview over
all the tickets.

However, with a *feature* you rarely know beforehand how it will look
like, in what it will help and how it will create new problems. So if a
dev writes a ticket for a new feature (and this _is_ a burden: She[1]
might just have a vague idea but is forced to write up a comprehensive
proposal) the cummunity might at best make a very uninformed decision
about a feature that would look completey different if it were developed.
If you have ever accompanied a development process, then you know that it
is _during_ that process that understanding of the issue emerges, that
concepts are overthrown and problems solved. Not beforehand.

IdeaChampioning is a concept that fosters communication _during_ the
development process. From your mail I gather that you have not understood
how it works (you are not to blame, as, ideed, it has not been documented).

> I don't think it is that easy. You are missing some cases here. Idea
> championing (whatever that exactly is, it has no wiki page :P ) doesn't
> work for all of them. The simplest case is that a user has an idea for a
> feature, works out some details and tells a developer. That's what I
> have done with the track parser: it came to my mind, I did a rough
> sketch of it on a wiki page, Stefan implemented it, lots of people liked
> it. Typical case for you idea champion stuff I guess.

No, it's not. It is not a one way process. IdeaChampioning also means to
champion your idea in the mailing lists in front of other _users_.
You will put it forward when peoploe point ot an issue that you think
would be solved by the idea (this will help you to understand other user's
views of the problems, to find flwas in your idea or imagined
implementation).
You will also have to 'shield' the dev from all the debates (and noise)
that take her attention from the thing only she can do: coding. You will
deal with the debates and give her condensed reports by mail, skype or
wiki pages (which will instantly document your feature).

So, let's see how this works in your examples.

> User Anton has an idea, developer Berta works on it for some days and
> puts it on the test server, users Carsten, Detlef and Frieda notice it
> and don't like it (or just some parts of it or the way it was
> implemented). They complain, one of them probably enters a ticket to
> remove it.

If Anton is a good idea champion, they will not enter a ticket but use the
mailing list. That is the public forum in which Anton started to discuss
the feature. That is where they will complain.

> The developer is pissed because she (Berta ;)) put lots of work in it.

If Anton does his job, he will be in between the raw complain and Berta.
He should use good communications techniques (mirror the other's POV,
"Yes, and" and all that jazz) to figure out, what exaclty pisses the
others off. There will very likely be some substance to the complain, and
picking this up can only make the implementation better. Once the
discussion has reached this point, Anton will pass the good bits over to
Berta in the medium they have decided to use for their collaboraton. Berta
will be pleased because she can go on hacking undisturbed and gets good
feedback (that she would never have thoght of).

> Carsten, Detlef and Frieda are pissed because Berta doesn't see why it
> should be removed,

In this case they should be relatively happy because their concerns have
been taken seriously. Note that this is the tricky part. Anton has to pay
close attention to a lot of things:
- that the debate does not evolve about "yes or no", "either you are with
us, or you are against us", but about the greyscales in between.
- that the tone of the debate remains productive. This can be difficult,
if Detlef is really negative about this. However, Anton's authority as an
IdeaChampion can help him to establish: "If you want to have some effect
on the development process, then you'll have to communicate with me in a
decent way."
- that maybe the others are just uninformed, he will have to offer
instant documentaition (yes, that is work).
- that there can be hurt feelings on both sides. He will have to pull the
emotional and the objective layers of the debate apart (hard work).

> eventually it gets removed anyways, now Anton is pissed.

If the communication was successful, then this should not happen. The
feature might turn out to become something entirely different from what
Anton and Berta imagined in the first place, but it should not be a matter
of "yes or no".

So, you see, IdeaChampioning is hard work, but it is work that gets
results. Provenly so: The AR interface and WikiDocs are there. They are
not perfect, but they fulfill their purpose (oh, what I'd love someone to
idea champion a better AR interface!).

> Or how about that: the developer changes the layout or the way the
> interface works thinking it is an improvement. Some users think the
> same, lots of users don't think so and want it to be changed back again,
> or changed in another way. This has nothing to do with idea championing
> at all. Of course good communication afterwards can help to change the
> changes in a way that more people will be happy. But how about some good
> communication *before* the work is done?

You hit the problem exactly on the spot. What the latest server release
has lacked completely was communication about the percieved issues
*during* the development process. And this goes to both parties, the dev
(Keschte) and the complainers. Yes this also goes directly to you in
person. I do not want to start blaming or looking for whose fault it was.
This is just an obersvation of what went wrong. Keschte has complained
that he did not _want_ to work alone on this release. Maybe we were just
missing a middleman who could foster communication about the UI
rearrangements while he was working on it.

Ad (b)

>> So instead of devising some complex and abstract QA scheme, I suggest
>> you just get something concrete done. Go and pick up some issue that
>> you feel is important and be its IdeaChampion and work together with a
>> dev. The IntuitivePicardInterface is one that springs into my mind, but
>> I am sure there are others.
>
> I don't think what I proposed is complex. And I thought it was quite
> concrete.

By abstract I mean that it is *policy*. It says what devs and users
*should* do.[2]
By concrete I mean to *do* some work on a very specific issue. If you feel
you have something at hand that should be put to a vote, then do it. If
you think you need feedback from newbs, then ask them.

In doing so you can create a policy. That is leading by example, or as I
say: "Rules follow practice".

> I can't get something concrete done because I'm not a developer of MB
> and probably never will be (this is partly a decision, partly my
> abilities).

I think that is wrong. You could do all of what I have described above.
The only reasons not to be able to do this are
- someone feels they do not have the social competencies to foster
communication like this [3].
- someone is not prepared to put in the energy and percistency that is
required to get an idea through to implementation.

>> And remember: Rules follow practice!
>> This means: If you actually *do* something and by doing so you
>> implement some aspects of the scheme you devised, then this might
>> become a rule. But not beforehand. We already broke our nose twice this
>> way.
>
> You are the expert but I think you see this a bit too strict. ;)

Well, the StyleCouncil broke down twice because of some abstract policies
that did not fit reality. And I certainly do not want the MB development
process to ever break down. So forgive my strictness. I will persit with
it.

I can only repeat: Pick up an idea or feature, push it through as *you*
think it should work. When you have succeeded, come back and propose a
policy based upon your concrete experience: Rules based upon practice. If
this turns out to be an alternative/better/second way compared to
IdeaChampioning, then I will be most happy with the result.

DonRedman

----
[1] Selective sexism: Today devs are female, because, let's face it, dudes
just don't know shit about coding. ;-)

[2] Just a note (if you feel attacked by this then I can understand it):
After the server release you had written a post about accessibilty [4]. I
was really pissed off from this, because I percieved it as an attempt of
political policy making. In my eyes it was completely counterproductive.
It took even more energy from both development and attemüts to undertand
each other, and instead fostered arguments about abstract "goals of MB"
between camps.
Working together with Steve and Keschte, maybe putting yourself in between
both and reformulating arguments so that the otherone can pick them up,
putting your won ideas into concrete mockups etc, *that* would have been
helpful.

[3] Please do not take _this_ as a personal attack. It is not intended to
be one. In fact it is directed at nobody in personal.

[4]
<http://www.nabble.com/Accessibility-and-usability---goals-of-MB--tf1915563s2885.html#a5244218>

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Feature "ratification" process

2006-08-07T12:36:03Z

Don Redman wrote:
> Well to be honest, I do not thik this will ever work. You will never
> find a volunteer programmer who writes a feature and then lets some
> people vote it down.

That's why I proposed adding tickets for bigger features which can have some sort of informal voting process to *prevent* getting done work rejected.
Which is better? Doing silent work, having people who don't like it and complain loudly - and then probably undoing the changes. Or good preliminary planing together with the community, *less* complaints, *less* worthless spent time?

> You will however find volunteer developers who pick up _all_ the
> feedback (even the one they do not like) and work together with people
> who are prepared to put energy in the issues they percieve to solve all
> issues (even the ones they do not understand). Robert said that he
> learned this the hard way a few years ago. Keschte is learning right
> now. :-)
>
> Remember that we have very few people doing actual development work.
> Putting even more weight on their shoulders can easily put the
> development to a total halt.

I don't want to put more weight on anyones shoulders. It's not that I want to put chains on the developers. Rather I want to improve the process such that the developers get the feeling the work they do is exactly what is wanted. Robert said it quite right: the developers are the people who make MB possible. They are not only machines who implement code for features that other people have in mind but actually they are the most inventive force in MB. People might have rough ideas about features, developers though have to bother with all the details. But! They are single persons who do the work the way *they* think it is best. That doesn't mean most of the users think the same. So they will get feedback anyways (quite as you said) and will have to get along with it (since it's the users they write the code for). I just propose changing the way the community is involved in the process, to make it better for both sides.

> Also note that we already *have* a system in place to help with these
> problems which works very well: Idea Championing. This is a possibility
> for non-hackers to help in the development process, to encourage early
> discussion with the community and to take weight from the dev's
> shoulders. Unfortunately this has not been used a lot lately. I have
> done this twice and it has worked quite well.

I don't think it is that easy. You are missing some cases here. Idea championing (whatever that exactly is, it has no wiki page :P ) doesn't work for all of them. The simplest case is that a user has an idea for a feature, works out some details and tells a developer. That's what I have done with the track parser: it came to my mind, I did a rough sketch of it on a wiki page, Stefan implemented it, lots of people liked it. Typical case for you idea champion stuff I guess.
But how about that: user Anton has an idea, developer Berta works on it for some days and puts it on the test server, users Carsten, Detlef and Frieda notice it and don't like it (or just some parts of it or the way it was implemented). They complain, one of them probably enters a ticket to remove it, the developer is pissed because she (Berta ;)) put lots of work in it, Carsten, Detlef and Frieda are pissed because Berta doesn't see why it should be removed, eventually it gets removed anyways, now Anton is pissed. Also a typical case for successful idea championing?
Or how about that: the developer changes the layout or the way the interface works thinking it is an improvement. Some users think the same, lots of users don't think so and want it to be changed back again, or changed in another way. This has nothing to do with idea championing at all. Of course good communication afterwards can help to change the changes in a way that more people will be happy. But how about some good communication *before* the work is done? Every software developing company does teamwork planning before writing a single line of code. I think an open source project should do that even more!

> So instead of devising some complex and abstract QA scheme, I suggest
> you just get something concrete done. Go and pick up some issue that you
> feel is important and be its IdeaChampion and work together with a dev.
> The IntuitivePicardInterface is one that springs into my mind, but I am
> sure there are others.

I don't think what I proposed is complex. And I thought it was quite concrete. I can't get something concrete done because I'm not a developer of MB and probably never will be (this is partly a decision, partly my abilities). But I'm adding tickets all the time. I think that's the best way for me to communicate with the developers.

> And remember: Rules follow practice!
> This means: If you actually *do* something and by doing so you implement
> some aspects of the scheme you devised, then this might become a rule.
> But not beforehand. We already broke our nose twice this way.

You are the expert but I think you see this a bit too strict. ;)

Greets,
Simon

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Feature "ratification" process

2006-08-06T15:25:42Z

On Sun, Aug 06, 2006 at 10:45:27PM +0200, Simon Reinhardt wrote:
> Either a user requests an RFE. We already achieved to be dispciplined
> enough to let this all be done over trac. Sometimes there is some
> discussion about the RFE on the ticket page for it, mostly between the
> requesting user and a developer, rarely with other community members.
> Then if the developer decides the feature is worth implementing, they
> implement it and let the result go live on the test server.

One problem I've noticed with this method is that when a developer does do
the change, someone else tends to come along and report a bug for it to be
changed back. Having more community input rather than just input from the
person requesting the changes/features would, hopefully, help reduce that.
I know I sometimes look at the bug/feature list and think "but how many
people even *want* that?".

> Another thing which could help with this process is - rob mentioned that?
> - to have a test server farm where people can implement features and let
> others decide whether they are good or not.

I want to expand on that... Right now, for people with svn access, the
development process generally goes like so:
* developer thinks of a good idea
* developer implements it and commits it to svn
* test server is updated
* a: people testing come across the feature, hate it and complain
* result a: chaos, hurt feelings, etc.
* b: people testing come across the feature and like it
* result: success
but there's no way of knowing just which outcome we'll get.

With a test server farm and more discussion the process could be:
* developer posts about an idea
* people like it
* developer implements it on a test server
* people comment on it
* developer makes improvements
* last two steps are repeated until the feature is deemed satisfactory
* feature is commited to svn
This has the advantage that features aren't released in a state where lots
of people are still unhappy about how it works.

or:
* developer posts about an idea
* people don't like it
* developer saves time and work

While these are pretty idealistic scenarios, I think getting people's
opinions *before* putting lots of effort in would be very helpful. I've
noticed that for an open project, we don't give people much information on
what's going on behind the scenes, new features just materialise whether
people want them or not. Also, I think testing particular features
separately is also easier for people because they've got something to focus
on. I know I never know where to start when testing!

--Nikki

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Feature "ratification" process

2006-08-06T15:06:05Z

Well to be honest, I do not thik this will ever work. You will never find
a volunteer programmer who writes a feature and then lets some people vote
it down.

You will however find volunteer developers who pick up _all_ the feedback
(even the one they do not like) and work together with people who are
prepared to put energy in the issues they percieve to solve all issues
(even the ones they do not understand). Robert said that he learned this
the hard way a few years ago. Keschte is learning right now. :-)

Remember that we have very few people doing actual development work.
Putting even more weight on their shoulders can easily put the development
to a total halt.

Also note that we already *have* a system in place to help with these
problems which works very well: Idea Championing. This is a possibility
for non-hackers to help in the development process, to encourage early
discussion with the community and to take weight from the dev's shoulders.
Unfortunately this has not been used a lot lately. I have done this twice
and it has worked quite well.

So instead of devising some complex and abstract QA scheme, I suggest you
just get something concrete done. Go and pick up some issue that you feel
is important and be its IdeaChampion and work together with a dev. The
IntuitivePicardInterface is one that springs into my mind, but I am sure
there are others.

Yes this needs some competences in good communication and this needs some
persistence. That's life. :-)

And remember: Rules follow practice!
This means: If you actually *do* something and by doing so you implement
some aspects of the scheme you devised, then this might become a rule. But
not beforehand. We already broke our nose twice this way.

Cheers,

DonRedman

On Sun, 06 Aug 2006 22:45:27 +0200, Simon Reinhardt wrote:

> Hi,
>
> I just had this random idea how to improve the development process and
> make the end result be what the community wants as well as giving the
> developer the knowledge their work is wanted and not wasted. I know,
> this sounds like an utopic all-in-one solution ("egg-dropping
> woolmilksow" as we say in .de), but perhaps it could work.
>
> Let me first describe the current process. Basically there are two ways
> of new features to be added or changes to be made. Either a user
> requests an RFE. We already achieved to be dispciplined enough to let
> this all be done over trac. Sometimes there is some discussion about the
> RFE on the ticket page for it, mostly between the requesting user and a
> developer, rarely with other community members. Then if the developer
> decides the feature is worth implementing, they implement it and let the
> result go live on the test server.
> Another way is that the developers have ideas for new features or
> improvements themselves. They will then implement them - sometimes with,
> sometimes without ticket - and put them on the test server.
> This is all logged through the tickets and changesets on trac. It is
> accessible for everyone, yet very few people if any follow this and
> mostly other users note the changes on the test server or even not until
> it goes live and they have to use it the first time. So most of the time
> the development process happens silently and decisions are done by the
> developers.
>
> This causes: people who don't like the new features / the changes (the
> developer might think it is better, but different people have different
> opinions). Either they complain about the changes and annoy the
> developers or they don't say anything because they fear annoying the
> developer knowing it was a lot of work. Good communication in the golden
> middle happens rarely because not everyone is an expert in good
> communication (including me ;)).
>
> How could this be changed? What I have in mind is some sort of
> "ratification" process. This would include the following:
> - Developers add tickets for their own feature ideas (only for the
> bigger ones, not for changes of cell heights or stuff like that).
> - Proposed features are discussed by the community before work on them
> is started, so that the developer can be sure what they implement is
> wanted by the community and they don't waste time working on
> implementations which are rejected.
> - Changes on the server code are handled with a voting system similar to
> that we use for the MB data:
> - Changes which the developers consider trivial will just be applied
> - However for bigger changes they can and should (requires some
> self-discipline) put for a vote. Everyone (or just "major
> contributors"?) can take part in that and decide if they like it or not.
> If the change is related to a ticket and there has been enough
> discussion on the ticket before, then the change will surely be accepted
> (requires self-discipline on side of the users). For changes which are
> not related to a ticket, this is the first chance for the community to
> ratify them.
>
> So why should a developer put their own work to a vote? Isn't this a
> risk to let good work being rejected? - Well, what's the alternative? If
> it is just applied although people don't like it, then they will
> complain which produces hate and - if enough people complain - more work
> because the changes have to be undone. This is also a good reason for
> developers to create tickets for their own ideas: they can get the
> ratification/approval of the community *before* they start the work.
>
> It may sound like it slows down development but I think it actually
> reduces work and increases satisfaction on both sides.
>
> Another thing which could help with this process is - rob mentioned
> that? - to have a test server farm where people can implement features
> and let others decide whether they are good or not.
>
> Simon (Shepard)
>
> _______________________________________________
> Musicbrainz-experts mailing list
> Musicbrainz-experts@...
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
>

DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Feature "ratification" process

2006-08-06T15:05:17Z

> Hi,
>
> I just had this random idea how to improve the development process and make the end result be what the community wants as well as giving the developer the knowledge their work is wanted and not wasted. I know, this sounds like an utopic all-in-one solution ("egg-dropping woolmilksow" as we say in .de), but perhaps it could work.
>
> Let me first describe the current process. Basically there are two ways of new features to be added or changes to be made. Either a user requests an RFE. We already achieved to be dispciplined enough to let this all be done over trac. Sometimes there is some discussion about the RFE on the ticket page for it, mostly between the requesting user and a developer, rarely with other community members. Then if the developer decides the feature is worth implementing, they implement it and let the result go live on the test server.
> Another way is that the developers have ideas for new features or improvements themselves. They will then implement them - sometimes with, sometimes without ticket - and put them on the test server.
> This is all logged through the tickets and changesets on trac. It is accessible for everyone, yet very few people if any follow this and mostly other users note the changes on the test server or even not until it goes live and they have to use it the first time. So most of the time the development process happens silently and decisions are done by the developers.
>
> This causes: people who don't like the new features / the changes (the developer might think it is better, but different people have different opinions). Either they complain about the changes and annoy the developers or they don't say anything because they fear annoying the developer knowing it was a lot of work. Good communication in the golden middle happens rarely because not everyone is an expert in good communication (including me ;)).
>
> How could this be changed? What I have in mind is some sort of "ratification" process. This would include the following:
> - Developers add tickets for their own feature ideas (only for the bigger ones, not for changes of cell heights or stuff like that).
> - Proposed features are discussed by the community before work on them is started, so that the developer can be sure what they implement is wanted by the community and they don't waste time working on implementations which are rejected.
> - Changes on the server code are handled with a voting system similar to that we use for the MB data:
> - Changes which the developers consider trivial will just be applied
> - However for bigger changes they can and should (requires some self-discipline) put for a vote. Everyone (or just "major contributors"?) can take part in that and decide if they like it or not. If the change is related to a ticket and there has been enough discussion on the ticket before, then the change will surely be accepted (requires self-discipline on side of the users). For changes which are not related to a ticket, this is the first chance for the community to ratify them.
>
> So why should a developer put their own work to a vote? Isn't this a risk to let good work being rejected? - Well, what's the alternative? If it is just applied although people don't like it, then they will complain which produces hate and - if enough people complain - more work because the changes have to be undone. This is also a good reason for developers to create tickets for their own ideas: they can get the ratification/approval of the community *before* they start the work.
>
> It may sound like it slows down development but I think it actually reduces work and increases satisfaction on both sides.
>
> Another thing which could help with this process is - rob mentioned that? - to have a test server farm where people can implement features and let others decide whether they are good or not.
>
> Simon (Shepard)

I like this idea!
I think it will need a tiny-bit remodeling to work in the scheme of mb (altough I wouldn't know how or which part)
but I think this could work. I can clearly see how this can make the developemnt easier, I especially agree with "and they don't waste time working on implementations which are rejected."
If *I* was a developer, I'd surly like that.
it would potentially make the work much faster too, because developers then could focus on parts that people *really* wanted to be changed
and they would in return reap alot more sweets than thorns for their trouble.

~mo :D

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Feature "ratification" process

2006-08-06T14:44:26Z

Hi,

I just had this random idea how to improve the development process and make the end result be what the community wants as well as giving the developer the knowledge their work is wanted and not wasted. I know, this sounds like an utopic all-in-one solution ("egg-dropping woolmilksow" as we say in .de), but perhaps it could work.

Let me first describe the current process. Basically there are two ways of new features to be added or changes to be made. Either a user requests an RFE. We already achieved to be dispciplined enough to let this all be done over trac. Sometimes there is some discussion about the RFE on the ticket page for it, mostly between the requesting user and a developer, rarely with other community members. Then if the developer decides the feature is worth implementing, they implement it and let the result go live on the test server.
Another way is that the developers have ideas for new features or improvements themselves. They will then implement them - sometimes with, sometimes without ticket - and put them on the test server.
This is all logged through the tickets and changesets on trac. It is accessible for everyone, yet very few people if any follow this and mostly other users note the changes on the test server or even not until it goes live and they have to use it the first time. So most of the time the development process happens silently and decisions are done by the developers.

This causes: people who don't like the new features / the changes (the developer might think it is better, but different people have different opinions). Either they complain about the changes and annoy the developers or they don't say anything because they fear annoying the developer knowing it was a lot of work. Good communication in the golden middle happens rarely because not everyone is an expert in good communication (including me ;)).

How could this be changed? What I have in mind is some sort of "ratification" process. This would include the following:
- Developers add tickets for their own feature ideas (only for the bigger ones, not for changes of cell heights or stuff like that).
- Proposed features are discussed by the community before work on them is started, so that the developer can be sure what they implement is wanted by the community and they don't waste time working on implementations which are rejected.
- Changes on the server code are handled with a voting system similar to that we use for the MB data:
- Changes which the developers consider trivial will just be applied
- However for bigger changes they can and should (requires some self-discipline) put for a vote. Everyone (or just "major contributors"?) can take part in that and decide if they like it or not. If the change is related to a ticket and there has been enough discussion on the ticket before, then the change will surely be accepted (requires self-discipline on side of the users). For changes which are not related to a ticket, this is the first chance for the community to ratify them.

So why should a developer put their own work to a vote? Isn't this a risk to let good work being rejected? - Well, what's the alternative? If it is just applied although people don't like it, then they will complain which produces hate and - if enough people complain - more work because the changes have to be undone. This is also a good reason for developers to create tickets for their own ideas: they can get the ratification/approval of the community *before* they start the work.

It may sound like it slows down development but I think it actually reduces work and increases satisfaction on both sides.

Another thing which could help with this process is - rob mentioned that? - to have a test server farm where people can implement features and let others decide whether they are good or not.

Simon (Shepard)

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Add artist edits, should they be automatically applied?

2006-07-27T04:02:42Z

Nikki wrote:
[...]
> So, any objections or concerns?

I've checked in the code to the svn.

-Lukáš

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Terminology for NGS

2006-07-25T07:13:40Z

2006/7/24, Jan van Thiel <zout@...>:
> On 7/12/06, Stefan Kestenholz <keschte@...> wrote:
> > my proposal to use "ReleaseGroup" still stands, even if we do not introduce
> > different types of grouping objects. (i see no reason why not, better to do
> > it right the first time, introduce the ones we'll need, or at least make it
> > easily extendeable like the relationships)
>
> Maybe something with the word 'Grouping' in it? ReleaseGrouping?

I was about to suggest Album :-D

Maybe we will keep it, after all...

--
Frederic Da Vitoria

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Terminology for NGS

2006-07-24T11:01:13Z

On 7/12/06, Stefan Kestenholz <keschte@...> wrote:
> my proposal to use "ReleaseGroup" still stands, even if we do not introduce
> different types of grouping objects. (i see no reason why not, better to do
> it right the first time, introduce the ones we'll need, or at least make it
> easily extendeable like the relationships)

Maybe something with the word 'Grouping' in it? ReleaseGrouping?

--
Jan van Thiel (zout)

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Album name suck in 'pending changes' mode

2006-07-23T16:31:01Z

On Sun, 23 Jul 2006, Matt Perry wrote:

> This album appears to be stuck in pending changes mode for several weeks:
> http://musicbrainz.org/release/353a71f2-5da8-46d7-9e49-488481a2ed07.html
>
> I tried editing it and editing it back to see if that could clear
> things. No recent entries in the mod history. DB problem maybe?

It was because http://musicbrainz.org/show/edit/?editid=4482923 was
approved. When approving was first introduced there was a little bug,
which has since been fixed, but the symptoms of it still exist in some
places.

For each edit opened against an object, a modpending value is incremented,
as each one closes, the value is decremented. When there is nothing
pending it should be at zero and the yellow indicator won't show.

In this case the value is:

musicbrainz_db=# select name, gid, modpending from album where id=120523;
name | gid | modpending
-------------+--------------------------------------+------------
The Beatles | 353a71f2-5da8-46d7-9e49-488481a2ed07 | -1

it has dropped below zero!

A script needs writing and running to fix the modpending values, but it
isn't high priority.

I can't remember if a ticket has been raised for this or not. I know one
was raised at the time for the approve bug, but that might have been
closed.

Steve

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Album name suck in 'pending changes' mode

2006-07-23T16:04:33Z

This album appears to be stuck in pending changes mode for several weeks:
http://musicbrainz.org/release/353a71f2-5da8-46d7-9e49-488481a2ed07.html

I tried editing it and editing it back to see if that could clear
things. No recent entries in the mod history. DB problem maybe?

--
Matt Perry | matt at primefactor dot com

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Blind voting

2006-07-18T16:34:04Z

>> To be influenced by other peoples opinion is a very natural thing, you
>> can't
>> know about all the stuff that has been put up to a vote. But the system
>> demands that people vote on edits, and lots of edits are applied after 1 or
>> 2 weeks without much proof if they were valid or not. So, on obscure
>> artists, if there was one or two yes votes, I'd be glad to give it a final
>> push, such that it gets applied rather than staying open and collecting
>> numerous abstain votes, but I'd never open the detail page to see if there
>> actually are votes or not.
>
> can i expect a response on this, or is the subject closed?

I totally agree with Don's remarks in:

http://lists.musicbrainz.org/pipermail/musicbrainz-experts/2006-July/000494.html

It should be set back to the old behaviour at the moment.

Any decision to remove blind voting needs to be discussed community wide
and the impact fully assessed.

I believe the ticket is still open http://bugs.musicbrainz.org/ticket/1825

Steve

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Blind voting

2006-07-18T16:19:21Z

> To be influenced by other peoples opinion is a very natural thing, you can't
> know about all the stuff that has been put up to a vote. But the system
> demands that people vote on edits, and lots of edits are applied after 1 or
> 2 weeks without much proof if they were valid or not. So, on obscure
> artists, if there was one or two yes votes, I'd be glad to give it a final
> push, such that it gets applied rather than staying open and collecting
> numerous abstain votes, but I'd never open the detail page to see if there
> actually are votes or not.

can i expect a response on this, or is the subject closed?

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

RE: Blind voting

2006-07-17T17:37:45Z

> You should vote purely on your experience and the merit of the edit in
> question.
>
> Dealing with in any other way has the same impact as rigging a
> presidential election!

If the debate was really that long when this was decided (must have been
before I've gotten serious with MB) then certainly other people must have
felt otherwise.

To be influenced by other peoples opinion is a very natural thing, you can't
know about all the stuff that has been put up to a vote. But the system
demands that people vote on edits, and lots of edits are applied after 1 or
2 weeks without much proof if they were valid or not. So, on obscure
artists, if there was one or two yes votes, I'd be glad to give it a final
push, such that it gets applied rather than staying open and collecting
numerous abstain votes, but I'd never open the detail page to see if there
actually are votes or not.

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

RE: Blind voting

2006-07-17T17:23:46Z

On Tue, 18 Jul 2006, Stefan Kestenholz wrote:

>> Again. As of now I consider this a bug that should be fixed. If you want
>> to change this, you are free to start a discussion and ask for oppions
>> (currently you have inhouseuk's and mine).
>
> Ok, I don't feel as strongly about, and I'm sorry, I did not know about
> this, and found this a rather annoying thing, having to open the detail view
> for cases where I was not sure if I should follow the example of other users
> or just press on "abs". This is what a majority of users do, I assume.

The answer here, you should never allow yourself to be influenced by the
way that other people vote.

You should vote purely on your experience and the merit of the edit in
question.

Dealing with in any other way has the same impact as rigging a
presidential election!

Steve

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

RE: Blind voting

2006-07-17T16:42:50Z

> Again. As of now I consider this a bug that should be fixed. If you want
> to change this, you are free to start a discussion and ask for oppions
> (currently you have inhouseuk's and mine).

Ok, I don't feel as strongly about, and I'm sorry, I did not know about
this, and found this a rather annoying thing, having to open the detail view
for cases where I was not sure if I should follow the example of other users
or just press on "abs". This is what a majority of users do, I assume.

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Blind voting

2006-07-17T16:36:12Z

On Mon, 17 Jul 2006 09:33:56 +0200, Stefan Kestenholz wrote:

>> I remember that there was a very long debate about how to handle display
>> of cast votes a long time ago. IIRC it was when we were introducing the
>> vote count on the edit details page. The decision was that it was ok on
>> the details page but should not show on the voting overview nor in the
>> iframe.
>
> This was probably a time when there weren't 6000 open edits in the
> system at all time. Any feature that allows to more quickly assess the
> state of an edit is a good feature, i think - even if it might be a
> bit populistic, it is _not_ such a big deal if an edit would be failed
> because of the influence of another vote.

Well I strongly disagree. What I say is that there was a community
decision after a long debate. And there were a lot of open edits then
(even if not 6000).

What I say is that neither your personal design decision nor a discussion
on IRC should override such a community decision. Another debate with new
consensus can.

In fact these details can have a huge impact on the entire dynamics of
MusicBrainz (this is the sociologue speaking again). The way people vote,
the way open edits stay in the system form a rather delicate cybernetic
system. And the question which information is available where plays an
important role in the resulting dynamics.

> in my opinion, the advantages outweight the ethical aspect of showing
> the vote tally on edits a user hasn't voted on.

Um sorry, but ethical aspects are never outweighted by practical
advantages (e.g. you do not outweight the ethical aspect of not giving our
user's email addresses away with the practical advantage of $100.000).

Again. As of now I consider this a bug that should be fixed. If you want
to change this, you are free to start a discussion and ask for oppions
(currently you have inhouseuk's and mine).

DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Blind voting

2006-07-17T01:33:56Z

> I remember that there was a very long debate about how to handle display
> of cast votes a long time ago. IIRC it was when we were introducing the
> vote count on the edit details page. The decision was that it was ok on
> the details page but should not show on the voting overview nor in the
> iframe.

This was probably a time when there weren't 6000 open edits in the
system at all time. Any feature that allows to more quickly assess the
state of an edit is a good feature, i think - even if it might be a
bit populistic, it is _not_ such a big deal if an edit would be failed
because of the influence of another vote.

sometimes users only leave notes and do not vote, in other cases they
vote but do not leave messages, which is bad given the CodeOfConduct.
it's very clear than we usually miss those cases when skipping over
the list of open edits, unless you go and open each and everyone to
see if they have negative votes unless you actually voted (i do not
revisit edits i voted on, unless notes are added to them).

in my opinion, the advantages outweight the ethical aspect of showing
the vote tally on edits a user hasn't voted on.

> Note that this is not intended as criticism to what happened here. Keschte
> has changed many subtle details on the server. I can understand very well
> if he just asked for a small feedback on IRC and then went on with his
> work.

thanks.

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Please give your opinions on the "Edit all" page

2006-07-16T14:00:04Z

This is a rather important topic, therefore i hereby notify readers who
might not be subscribed to mb-users of a discussion which I feel is very
important that people who want something to say should speak up.

http://www.nabble.com/%22Edit-All%22---Is-it-problematic-to-understand--tf19
50904s2885.html

regards, keschte

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Blind voting

2006-07-16T12:29:31Z

On Sun, 16 Jul 2006 16:00:43 +0200, Steve Wyles wrote:

> The recent server release has totally removed the blind voting element.
>
> This means that voters can now be easily influenced by previous votes
> rather than voting purely based on their own experience and merit of the
> edit being made.
>
> Although, it was previouly possible to find out the vote by using the
> show edit page, current votes were always hidden in the voting iframe
> and within the search edit pages until the editor had actually voted.
>
> Allegedly there was some discussion on IRC, but it should have been
> discussed wider in the community before making this change, hence this
> email.

I do not think IRC is the right place to make such a decision. The people
who are on IRC are only a subset of the MB community and there are both
old-timers and active newbies whose feedback you will never get if you
have such a debate on IRC only.

I remember that there was a very long debate about how to handle display
of cast votes a long time ago. IIRC it was when we were introducing the
vote count on the edit details page. The decision was that it was ok on
the details page but should not show on the voting overview nor in the
iframe.
This way people can have an _intential_ look at the previous votes, but
this is not given as an initial clue. I do not see what has changed in MB
that this would not make sense any more.

In general I would like a policy about not making community decisions on
IRC (unless this is announced on a mailinglist or something like that).

Note that this is not intended as criticism to what happened here. Keschte
has changed many subtle details on the server. I can understand very well
if he just asked for a small feedback on IRC and then went on with his
work.

DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Blind voting

2006-07-16T08:00:43Z

The recent server release has totally removed the blind voting element.

This means that voters can now be easily influenced by previous votes
rather than voting purely based on their own experience and merit of the edit
being made.

Although, it was previouly possible to find out the vote by using the
show edit page, current votes were always hidden in the voting iframe and
within the search edit pages until the editor had actually voted.

Allegedly there was some discussion on IRC, but it should have been
discussed wider in the community before making this change, hence this email.

http://bugs.musicbrainz.org/ticket/1825 is the related bug report.

Steve (inhouseuk)

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Terminology for NGS

2006-07-13T18:45:09Z

Frederic Da Vitoria wrote:

> 2006/7/13, Don Redman <donredman@...>:
> > Looking at FRBR maybe the term "Work" would be appropriate. But in fact,
> > when I look at FRBR and keep the problems we recently had about what
> > makes
> > a release (current terminology), then I cannot help but feel that the
> > vertical bamboo is flawed. The relations between release, release event
> > and medium are strange. We noticed that on the summit but had more urgent
> > things to discuss.
>
> Work is often used for what NGS names Composition. I fear using this
> word here would confuse people.

In my mind, there is no end to the number of levels of "works"
based on each other. A melody is composed, a songtext is written,
then the song text is translated to another language and the
melody is arranged for an orchestra setting, then the combination
is performed by a collaboration of a band and a guest artist, and
recorded by a recording studio, and released (or re-released 20
years later) by a record company (which can be diffferent from the
recording company, at least in the case of a re-realease).

The computer science way (this is not based on FRBR) to deal with
such complexities is to build a data structure for a generic tree
node, with which arbitrarily large trees can be constructed.
Like LEGO blocks. So don't build "composer" or "work" or "release"
into the data model. Make them flexible attributes to a generic
tree node. And keep this flexibility all the way through the web
interface. The latter is probably the biggest challenge.

class work {
title;
date; # when it was made
kind; # kind of work, e.g. "text translation"
creators; # list of pointers to "artists"
based_on; # list of pointers to other works;
}

For the discussion of a future MB data model, this would *reduce*
the number of database tables, in that the album (release) table
can be merged with the track table. The album/release would be
"based_on" a number of tracks, each having their own tree node.
A "boxed set" would likewise be a node being "based_on" a list of
discs.

These are just some lose thoughts, and not at all ready for
implementation.

--
Lars Aronsson (lars@...)
Aronsson Datateknik - http://aronsson.se

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Terminology for NGS

2006-07-13T05:53:31Z

2006/7/13, Don Redman <donredman@...>:
> Looking at FRBR maybe the term "Work" would be appropriate. But in fact,
> when I look at FRBR and keep the problems we recently had about what makes
> a release (current terminology), then I cannot help but feel that the
> vertical bamboo is flawed. The relations between release, release event
> and medium are strange. We noticed that on the summit but had more urgent
> things to discuss.

Work is often used for what NGS names Composition. I fear using this
word here would confuse people.

--
Frederic Da Vitoria

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Terminology for NGS

2006-07-12T16:25:34Z

On Wed, 12 Jul 2006 10:08:23 +0200, Stefan Kestenholz wrote:

> In any case, i like CreditedArtist much better than AttributedArtist.

Agreed.

> my proposal to use "ReleaseGroup" still stands, even if we do not
> introduce
> different types of grouping objects. (i see no reason why not, better to
> do
> it right the first time, introduce the ones we'll need, or at least make
> it easily extendeable like the relationships)

I do not like ReleaseGroup. This entity is not about releases, so it
should not contain that term. Otherwise the Composition could also be
called a TrackGroupGroupGroupGroup. :-) Something which states what it is
-- not what it groups -- would be preferable.

Looking at FRBR maybe the term "Work" would be appropriate. But in fact,
when I look at FRBR and keep the problems we recently had about what makes
a release (current terminology), then I cannot help but feel that the
vertical bamboo is flawed. The relations between release, release event
and medium are strange. We noticed that on the summit but had more urgent
things to discuss.

Maybe FRBR can help to sort this mess out? (CC to Lars Aronsson in this
respect).

DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts

Re: Terminology for NGS

2006-07-12T02:08:23Z

after reviewing the objectmodel graph again, i think i was misunderstanding the request too. Since the object named "ReleaseArtist" is used in two different cases (ReleaseArtist as well as TrackArtist) i now understand much better why you are not happy with the current terminology. In any case, i like CreditedArtist much better than AttributedArtist.

my proposal to use "ReleaseGroup" still stands, even if we do not introduce different types of grouping objects. (i see no reason why not, better to do it right the first time, introduce the ones we'll need, or at least make it easily extendeable like the relationships)

--keschte

PS. Cluster doesn't feel like an adequate term for me, and it is correct that it didn't work out for Picard. i've tried to find references to the dicussion about clusters, the best i was able to come up with was a thread in january 2006.

http://lists.musicbrainz.org/pipermail/musicbrainz-users/2006-January/010598.html

_______________________________________________
Musicbrainz-experts mailing list
Musicbrainz-experts@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts