Addressing MusicBrainz' growing problems: part 3

Part 3 talks short term solutions to problems — things to tackle immediate problems: (also see part 1 and part 2)

Bugs mailing list: In order to solve the problem of opacity of the bug system (its hard to see what people are saying in bug reports unless you spend quite a bit of time following bug reports) I’m going to implement the bug triage suggestion. With this system, every time a bug is submitted or changed an email is posted to the new musicbrainz-bugs mailing list. This will allow more people to monitor the flow of bug reports. (This is almost done, but I am experiencing problems setting up the new mailing list — I’ll need to wait for Dave to return from holidays)

Forums: It appears that even the sternest nay-sayers on forums agree that its time to get these set-up. I’ve asked Lukas to see if he is still interested in spearheading this effort. UPDATE: Lukas is still interested in taking care of this.

Mirror and test server maintainers wanted: Maintaining the nl. mirror and the test/staging server is work I would like to give to someone else. The test server in particular needs work to make many sandboxes for new developers to come in and play with mb_server without having to install a whole setup on their own machine. Anyone interested in this job should be reasonably familiar with mb_server. Send me mail or post a comment if you can help!

support@: As mentioned in part 1, I could use more help with mails sent to support@. Wolfsong has been graciously helping this this task, but as it happens with volunteers he gets busy with real life from time to time. Zout joined the effort to answer emails today and I am wondering if there are other people who would like to help with this. I’d like to have a team of people answer mails sent to support@ and info@ on a first come, first serve basis. Send me mail or post a comment if you’d like to help out.

Conflict resolution: During the August IRC chat we discussed the need for an official body of people to help with conflict resolution here at MusicBrainz. Its clear that conflict resolution is a task to be handled by more than one person in public. I’m currently attempting to find a moderator and a suitable time to have this discussion. My hope is to do this on a Sunday so that as many people as possible can jump into this chat. I’ll post details when I have them.

Stefan: I’ve mailed Stefan to see if he was even interested in being a MusicBrainz developer again. He didn’t give me a clear answer, so I will wait for concise word from Stefan on this issue.

Part 4 will talk about documenting the MusicBrainz development process — more tomorrow.

Technorati Tags: , ,

6 thoughts on “Addressing MusicBrainz' growing problems: part 3”

  1. I’m wondering if it might be worth having the support@ emails go straight into trac using something like

    They will then be allocated an ‘incident number’ and dealt with by people that have access to the component area. It’s certainly something that is worth investigation.

  2. I’m not a programmer and I’m not 100% sure how the process works so if this is a little off bear with me. I’d like to see a blog (or maybe this can be in the forums somehow) where server changes that will eventually go live are posted for testing to the public so we can participate in the process. It would be like a dynamic “change log”; Stefan or any other programmer who makes a change would post it there for others to test and comment. Even the smallest changes would be posted with a description of how it’s supposed to work; this way the programmers can use it as a notepad for what changes have already been made, and normal users can test and feedback the change. Whether or not the programmer acts or responds to the feedback is still up to them but it provides a place to discuss changes that are made. For example:

    Change #236, Fixed firefox display bug (bug # 2036) – When merging two albums together, the buttons no longer overlap at the bottom of the screen. Test here: [link to test server album]

  3. About support@. You should probably be a bit more precise on what kind qualifications people interested in helping with support@ should have.

  4. I think it might be a good idea to clarify a bit on what is needed from people interested in helping with support@.

  5. In addition or instead of a bugs mailing list, it might be useful to post an IRC message in the MB channel automatically as soon as a new ticket is submitted. I think it might result in more direct actions then to introduce a new mailing list.

Comments are closed.