Perhaps the avatar feature could simply be offloaded to gravatar.com, many sites are already using it. It would remove the need to upload/resize/store/serve avatar image files on MB servers.

The original ticket asks for

a) avatar
b) gender
c) birth year
d) country

And I would add
e) language(s) spoken and level of fluency (beginner/intermediate/expert)

I think all of those should be doable, with avatar maybe being somewhat harder (and also somewhat less important IMO, but if possible, that's better). Languages and countries can re-use our current lists.

Note that gravatar has privacy issues [1], even when the user hasn't signed up for gravatar.

We previously decided not to include gravatar support for this reason:

http://lists.musicbrainz.org/pipermail/musicbrainz-users/2009-April/019147.html

(note that I broke links on my site, the linked post is now at https://320x200.org/2009/gravatar/ )

[1] Note that the privacy problems can be avoided, but that means we need to serve the images ourselves, which probably isn't worth the trouble.

We could have a check box that says: Use gravatar with my email to show my avatar. This way people can opt out of using gravatar.

This ticket is under consideration for the May 15h schema change release. However, it is under specified at this point in time. In order to keep this ticket in consideration for the release, please do the following:

• Specify exactly what the user interface changes will be. Mock ups would be great. Due date: April 2
• Specify exactly what the database changes will be. We will need to have an exact database table change proposal. Exactly which columns will be added/removed/modified and what new tables will be created. If you cannot specify the changes to be done, chase down a developer to specify them for you. Due date: March 26

Nicolás has asked me to provide a database schema, so here's what I'd add:

The editor table will have the following extra columns:

• birth_year: integer, check constraint that it's >= 1900 (with only 10 people verified alive before 1900 at time of writing, I think this is a sensible check ). Can take NULL values.
• gender: FK to the gender table. Can take NULL values.
• country: FK to the country table. Can take NULL values.

Add an editor_languages table, with columns:

• editor (FK to editor table). Not NULL.
• language (FK to language table). Not NULL.
• fluency, which will take values from a new fluency data type. The values of this data type need to be defined in this ticket. Not NULL.
• Primary key over editor/language.
• Indexes on language and editor

Before I decide how to handle avatars, please decide on how you want them to work. Are we going with Gravatars? Are we going to handle uploads to our servers? Will we allow hotlinking to other domains?

I suggest only supporting Gravatar, with the ability to disable it as suggested by Kuno and Rob.

The values of fluency should be something simple: Beginner / Intermediate / Expert / Native, I'd say.

Agreed on disable-able Gravatar then.

Ok, in that case a new preference for Gravatar being enabled might be the way forward. Should this be enabled for new users by default, or disabled?

I think it should be disabled by default for existing users, I don't mind either way for new users.

I'd prefer "basic" rather than "beginner" and "advanced" rather than "expert" ("expert" in particular just sounds like bragging : P)

That works too, I just shamelessly copied the levels from Couchsurfing

Proposed schema changes:

ALTER TABLE editor ADD COLUMN birth_year SMALLINT;
ALTER TABLE editor ADD COLUMN gender INTEGER;
ALTER TABLE editor ADD COLUMN country INTEGER;

ALTER TABLE editor ADD CONSTRAINT editor_fk_gender FOREIGN KEY (gender) REFERENCES gender (id);
ALTER TABLE editor ADD CONSTRAINT editor_fk_country FOREIGN KEY (country) REFERENCES country (id);

CREATE TYPE FLUENCY AS ENUM ('basic', 'intermediate', 'advanced', 'native');

CREATE TABLE editor_language (
    editor INTEGER NOT NULL REFERENCES editor (id),
    language INTEGER NOT NULL REFERENCES language (id),
    fluency FLUENCY NOT NULL,
    PRIMARY KEY (editor, language)
);

CREATE INDEX editor_language_idx_language ON editor_language (language);

For gravatar, I think just going with a allow_gravatar preference might be best.

I think gravatar should be disabled by default for new and existing users.

Gravatar does a terrible job of explaining the privacy issues to developers and users, so most users are not aware of them and are not able to make an informed choice even if we ask them.

This ticket is in danger of being rejected from the upcoming schema change release. Please provide UI mock-ups today.

if I could, I would down-vote this =)

Mockup attached for profile. I don't think it's needed for editing but if it is please do tell.
Zaphod: see title, "optional".

Heh, while you're at it, why not allow for the editor to set and display a link to their MB artist entry (if they have one)?

This ticket is now feature complete. For "represented artists" or whatever, please open a new ticket. Thanks!

It seems the point of "birth_year" is to show age, but a year is not enough to do that. If we want that, we really want a DOB attribute for editors.

Hmm, you do have a point there. Since adding that doesn't fit in the changes to the DB you already indicated, I guess we should stick to birth year?

The SQL we published was never meant to be final, only an indication. I think changing "birth_year" to "birth_date" is not a drastic enough change for there to be any problems, so I am going to continue with that.

In review at http://codereview.musicbrainz.org/r/1873/diff/#index_header