I remember seeing that too.
When I first got to SE, I found it confusing and annoying to be forced to use Gravatar. I remember thinking “Just let me upload an image already!”. That would have saved me some work, and not required registering with yet another organization.
Yes, but please specify clearly what the image requirements are. Way too many sites make a mess of this. What you upload gets squished and squashed, or pixelated or over-filtered or whatever. Tell me the native size in pixels and the aspect ratio you want. If you’re going to show it at multiple sizes, tell me the size you need so that you can filter down to all the individual sizes nicely without introducing artifacts.
Once you decide on an aspect ratio, stick to it everywhere. If you say you want 1:1 (square), I’ll make a picture that works in a square format. Then don’t come along later and in some cases display it in a circle, or cut the sides off to fit into 2:3 or something.
I couldn’t agree with you more! (On this one, other stuff… 
)
This also relates to general image issues which I have raised. We can and should do a lot better than SE/imgur - and it is not hard to get it “right”. In this particular case, I would suggest something along the lines of:
Agreed in general. For MVP I think we only need upload of a profile picture and auto-scaling. Managing different sizes of profile pictures/avatars can come later – just make sure the aspect ratio doesn’t change.
For the DB schema, the relevant columns should use names like “picture” rather than “gravatar”, which implies a particular external service. (Yeah I know; as with “kleenex” and “xerox”, the word is fast becoming generic. But we don’t have to join in.)
Or choose “avatar”, which is the original word, from which gravatar originated.
So the DB equivalent of a // TODO comment?
IMHO project planning belongs neither in the code nor in extra DB tables or fields.
Also, I think it’s underestimating the community to assume that it will just be forgotten. If that actually happens, it wasn’t important.
Gravatar:
That discussion should be its own thread, as is it doesn’t have to do much with DB schemas. (Except that such things should be worked out before a schema containing them is made).
One important (IMHO) table that I don’t think ever made it in to the spec., except indirectly via discussions of gravatar, etc.: IMAGE Something like:
image
file_reference (Text 255) This will need work as we figure out how to actually store images (e.g., S3 vs. a regular file system)
directory (Text 255) A lot of ways to go here - I’d suggest a simple /yyyy/mm/dd/ to start - keeps each directory from getting too big without limiting things which would happen if we named directories based on member id or community etc.)
description (Text 255 default NULL)
height (int)
width (int)
type (enum - jpg, png, gif, tif, bmp, etc.) Minimum to support is png and jpg
original_source (enum - StackExchange, Imgur, etc.) This has licensing implications, but not importing images for imported posts would cause problems for a lot of content in some communities.
original_source_id (Text 255 default NULL)
Needs member id and upload (= creation) date/time, but those fields will be included by default as with other tables.
I am not sure how to handle references. The trick is that images are typically (using SE as an example, but I am sure they are not the only one) a tag referencing an ID inside markdown text, so a reference table is not as simple as with some other parts of the system. One option is to build an Image to Post reference table on the fly any time a Post is edited - i.e., scan it in the same way that the markdown text would be translated to create <img> tags and add/remove in the Image to Post table. References via Member Profiles, Avatars, etc. are simpler as those can be “you get one image or you can leave it blank” and just add an image_id field to those tables.
As noted elsewhere, there is plenty more that I want to do with images to make a big improvement over other systems (e.g., easy online crop, rotate, resize; create (either in advance or as-needed) different size images for fast loading; etc.) but those are not MVP and fields can be added later to handle them.
I would suggest we do not need a table for vote types
I think we need a table for vote types, having worked on systems with similar logic. There are two major reasons for this. #1, it makes it easy for someone just looking at the DB to figure out what is what without leaving the system. For example, is vote type 3 a Delete vote, or is it a Reopen vote? Or a Close vote? (Assuming #1 is Up and #2 is Down.) I don’t want to have to find the relevant enum in C# for this, and if we get a SQL specialist that doesn’t know C#, they might not even care about the code. #2, this table provides a primary key so we can’t insert a vote with id -1–the DB will catch us.
Suspensions should be a separate table IMO, as you need to be able to see past ones. Privilege-specific suspensions could be stored separately, but it’s probably simplest just to store them all in one place, with a special value for all privileges. Similarly for a network wide suspension the community_id would be NULL or something.