Enable the support for user profile pictures

The problem I forsee with this on drupal.org is the posts that already take a long time to load due to many comments. Adding more requests to long threads isn't going to be of benefit.

Webmasters can't do much about this as it would have to come from higher up. Infrastructure team may have to weigh in on this request.

I don't see a problem with just turning this on right now. Pictures would be served locally.

Subscribing. And I'm curious about why this is too. AFAIK the original d.o redesign mocks had user pictures in them.

Subscribe.

Let's do eet!

What does a to-do list look like?

* Create, approve and update design to accommodate images of the appropriate sizes.
- Within thread
- On profile
- On summary sidebar blocks (For "Topic pages" for example, for a hypothetical "who's following" block).

* Slurp images from g.d.o? Or people add in a new updated image?

* Test new design on sandboxes.

* Implement update to profiles.

* Inform ppl!

subscribe and tags

+1.

+1 to this. It'd be useful for many things, for example #1304558: Provide a page showing all the users following a given issue.

We'd have to think about how we want these to look on comments on issues (which are special-cased from other comments on this site). There are a lot of questions to answer about exactly where and how these would appear throughout d.o:

Issue nodes: yes
Issue comments: probably
Forum nodes: yes
Forum comments: yes
Documentation nodes: probably not
Documentation comments: probably
Project node author: probably not
Project node maintainer lists: probably?
Commits: yes (although it can get complicated with both the commit author and the committer (which aren't always the same identity).
Release nodes: no
Listings of followers: yes
... ?

All those places I said "yes" or "probably" should ideally get mockups or a basic spec for exactly how they're going to fit into each of these pages. Should probably copy this list into the issue summary so it can be collaboratively fleshed out and finalized.

So, I think there's a lot to design and get right before we just turn these on. But, I'd really like to see it happen, so let's get designing... ;)

Thanks!
-Derek

I'd really like to see this happen - it'd make attaching names to faces MUCH easier. :)

I am not sure about adding pictures to issue comments. Issues often are huge and contain lots of into which is hard to process as is. Not sure it is good to add even more stuff on these pages.

So my list would be:

Issue nodes: no
Issue comments: no
Forum nodes: yes
Forum comments: yes
Documentation nodes: no
Documentation comments: yes
Project node author: no
Project node maintainer lists: yes
Commits: no idea here
Release nodes: no
Listings of followers: yes
User profile page yes

I did some mock-ups for the ones where I said yes:
User profile page - size of user pic 85x85 px

Forums
main node - user pic 65x65 px
comments - 40x40 (documentation comments I suppose should look the same)

Project page - user pics 28x28 px

Great work on the mockups, tvn!

Doing it on issue nodes/comments would be a huge win for me for scannability. If I look at a long issue I want to be able to find comments by people I trust as quickly as possible. I can scan avatars many times faster than I can scan usernames. If they are too big we can just use an image style to make them smaller.

I agree. Seeing it on the maintainers block like that makes me drool and really want it for issue nodes/comments as well. :)

GREAT work, tvn!! Those mocks look fantastic.

Great work on the mockups!

I'd like to see the pictures be a consistent size everywhere we use them, though - the ones on the maintainers block are pretty small. Is there any reason not to use the full size picture and split the data onto multiple lines?

So rather than:

dereine - 1610 commits
last: 1 day ago, first: 1 year ago

We'd have:

dereine
1610 commits
last: 1 day ago
first: 1 year ago

(or something to that effect)

That way, we could use the full size user picture instead of a miniaturized one.

If we wanted to get REALLY crazy, we could turn it into a grid view instead of a list view. I'll open another issue to talk about this more, but the gist is that we'd have user pictures and usernames. When you hover over the picture, you'd get a little popup bubble with commit data.

Hm. I like the mockup the way it is, personally. These pictures are not the primary piece of data in that block, the information about commits is. Makes sense to use a smaller version of the picture. So too with comments vs. nodes.

There's no performance penalty as far as ImageCache is concerned for having multiple sizes, so let's go with what looks nice. :)

-1 to always using the same size. I think "inline" avatars make perfect sense in some places, as elegantly demonstrated by tvn's (awesome!) mockups.

Re: "Is there any reason not to use the full size picture and split the data onto multiple lines?"

Yes. ;) Because we don't want that block to take up all of the "above-the-fold" right sidebar on project pages.

These pictures are not the primary piece of data in that block

Actually, since the block is titled "Maintainers for whatever", I'd think it'd be focused on the people rather than the commit information.

I was thinking something like this:

When you hover over a face, you'd get something like this (but without my artistic deficiencies):

No, please don't make me mouseover for the important information I want to know. :(

Also, that breaks a pattern. Nowhere else does the user picture give me more information when I hover over it, so I'm not sure how a user would ever discover that this happens here.

separate issue: I think usernames/avatars *should* show relevant info. David Eaves suggested a "new" user flag and "Learning English". I'm not opposed to the pattern this introduces, but I agree with webchick we shouldn't have to hover to get the most relevant info.

Since this is likely to increase the amount of traffic we use, I want to point out that having a avatars of the same size would lend itself better to browser caching.

I also like to suggest to have an optional "no graphics" subtheme for those who prefer fast pages over ugly faces.

Eh, that can be done with user styles IMO. The caching bit is a good point though.

User styles allows me to hide the avatars, however I'll still need to d'l them unless I employ html rewriting. Don't think user styles do that.

So issue page:

I also think we could consider moving reply links on top: http://drupal.org/files/issue-page-2.png

Hm. I can see why you were leaning against having these in the issue queue. #27 still looks like it needs work.

What does it look like if there's a <br /> between "Posted by klonos" and "on October.."? The other images look great because the data they're next to spans two lines.

Another thought is putting the picture floated left underneath the "#xxx" in the comment.

Yeah, was thinking to try that too. Looks like this :

Or :

I like the first one - looks pretty good :)

First one in #29 is nice. :)

Not a big deal, but I think gravatar would be better than core user picture. Lots of folks have already specified a gravatar so the site would look awesome on day one. And not just one site, gravatar works across all our sites so we don't have to do any user profile sharing across all d.o. sites. If we go this way, IMO we can simply abandon the gdo images that folks have uploaded. We could just provide a little notice for folks to copy their pics to gravatar.

great to see that d.o. is becoming more "social". Little things like profile pictures make a big difference IMHO.

A popup over the username/userpicture to show more info like "join date, number of commits, etc" would be great too.

+1 for gravator, I already use it on StackExchange and StackOverflow. Plus have a module for that: http://drupal.org/project/gravatar

Tagging.

+1 for enabling profile pics

Interesting re: using Gravatar, but since we have profile pics on g.d.o., it would definitely enforce the notion that d.o. and g.d.o. are separate sites; I personally have a non-face Gravatar, but I have a face on g.d.o. If other users use separate pictures, it would negatively impact the ability to scan the avatars for someone you know.

Unless we decide to use Gravatar across all *.d.o. sites as well.

I'd prefer to stick as close to stock Drupal as possible, so that means just using the normal user picture upload field.

Hrm, I still want to throw support behind Gravatar. There's no need for us to be insistent that we have to use Drupal core features when there is a service out there that is widely supported and would avoid having to serve resources off of Drupal infrastructure. I'm going to be pushing that we replace user pictures in Drupal 8 core with Gravatar by default as well.

Granted, we could always add the Gravatar module to d.org which will allow people to upload their own avatar, or to use a Gravatar if one is not uploaded which would work for most users.

-- for external services.

greggles, could you send me the results of "SELECT MD5(mail), picture FROM {users} WHERE status = 1" from the g.d.o database so I could check how many users have a Gravatar compared to how many people have a user picture uploaded?

+1 for Gravatar. I can understand killes' hesitation, but I think it'd be a good idea in this case. Gravatar is pretty standard.

+1 for gravatar, much more useful than having upload another image to yet another site.

I am strictly against using Gravatar, unless there still will be the possibility to directly upload a picture on d.o, for those who don't want to use that service for one reason or another. For example, I might want to use face avatar on d.o and not want it to show up on any other site using Gravatar service. I generally think there always should be an option for users, we should not force people to use external services.

If Gravatar and core user pictures can work together, that sounds like the best plan. I'm -1 on adding user pictures in general but I know I'm in the minority. Requiring some 3rd party account for it sounds even worse. If you're going to have them, you should be able to have one without having to go sign up on some other site first.

Gravatars (as it works with the module) will always be overridden if you upload your own picture.

Just for the record: I am not against gravatar because it would require me to have an account with them in order to display a picture at d.o - I don't plan to upload one anyway.

I am against using an external service for user pics since this will allow that external service to track users on drupal.org.

Until #46, I didn't realize that gravatar.module allowed users to override their user pictures by uploading one. I really really like this plan - all users will get gravatar data unless they override it manually. Seems like a really good solution.

@#47, they *can*, but why would they? Also, if a user is really worried about it, then they can upload their own user picture to their profile and it's no longer an issue.

What if someone has a Gravitar picture but for whatever reason doesn't want anything on d.o at all? (Says the guy who has a very old picture on g.d.o and nowhere else and has considered removing the g.d.o picture, too...)

So instead of talking/theorizing, who wants to spear-head a d.o sandbox to get started on an implementation we can see/touch?

@Mark: You are quite mistaken. If I see _your_ gravatar pic on d.o, gravatar can in theory track _my_ movement on d.o and in-fact elsewhere if they set a cookie. I am not aware they are setting cookies for the time being, but this may change. In any case they can gather statistical data about drupal.org. Considering that gravatar is run by the wordpress guys this is to be considered too.

@Crell: I believe it's tied to your email so you could just use a different email, couldn't you?

Michelle: Google's asinine email handling causes me enough grief as is. No, I am not adding another email address to my Internet mix.

@Crell: Fair enough. I have 3 that I use routinely so I guess I'm just used to having multiples. I won't use Gravatar either way so it doesn't affect me as long as it's optional.

The hard part isn't turning on regular core profile pictures or dealing with Gravatar. We should have a single user picture across all subsites, we should not ask people to upload the same picture to Drupal.org, groups.drupal.org, association.drupal.org, all DrupalCon sites, and any others that start using pictures. This issue needs to be about making user pictures available on all sites.

I agree that user pictures *should* ideally be the same across all d.o sites, and I think Gravatar is a simple way to make it easy for those who use the service and don't want to bother uploading pictures anywhere else. I'm in favor of using Gravatar and allowing for the following options:
1) instead use an avatar just for d.o sites (anyone who uploads a user image)
2) just use the Gravatar-uploaded image (default)
3) show no image, even if Gravatar is available for associated email (opt-out checkbox)

I'm in favor of this too. I personally don't have a Gravatar account and I probably never will, but I still think this would be a great feature since most people tent to be "social" nowadays. Never mind my personal preference to not having a Gravatar account, I still use the contrib module on my sites and my customers' if they agree. We have to admit that it does enhance the social UX of a site ...almost atomagically!

We need to update the issue's summary with the concerns raised here (such as the possible performance hit) so we don't miss them as we implement this. One thing that wasn't discussed here is the possibility of gravatar.com being shut down (or locked or made commercial) in the future and what this means for d.o registered users that use this service for their profile pic (this is related to #334630: Cache gravatar images locally). For this specific concern, I think we should consider:

1. using Imagecache External to store the largest available image locally,
2. then process it with imagecache for our needs (for cases like when we need various avatar sizes in different parts of d.o as mentioned above for example),
3. we have it so that every while (cron run perhaps) a fresh version of the images is pulled from gravatar.com

This way, instead of having a couple of dozen requests (depending on the number of user comments) to an external source each time a forum/issue page is viewed, we serve the local version. I realize that this means that if users update their gravatar their change won't be "instant" in d.o. I guess we can either accept this as a trade-off or we figure a way to allow users to manually request their pic to be re-fetched from gravatar.com.

I read in #1508364: I want a drupal.org development site for user profile pictures that there was created a userpics dev site. Is that still on? Who's working on it? That info should be in the issue summary too.

I've updated the issue summary. Please take a look and update as you see fit or add anything I might have missed.

Another thing that might be worth considering/documenting is the upgrade path to D7 for the Port Drupal.org to Drupal 7 initiative.

...updating the issue summary to follow the issue summary standards + adding a few notes from various comments so far.

Well, the Gravatar module is available and stable for D7 and otherwise D7 is just much better equipped to handle images. I don't think we need worry too much about the "porting to D7" of this feature. See #55 for if Gravatar shut down (no big deal, users just upload a new avatar to d.o, if they choose).

Yes, I'm aware of these facts, the reason I'm mentioning things like these is because I don't want them to be "considered given" for some (us) and then others coming and asking again and again "just to make sure". They should at the very least be documented so that others don't wonder in the future and in order to reassure people that inclusion of the Gravatar project for example doesn't hinter our upgrade to D7 of drupal.org. As for the chance of gravatar.com closing in the future, again people should know that we have a "fallback" in place and that we've taken steps to make sure everything runs as smoothly as possible in case this ever happens ;)

This issue is postponed until there's a clearly defined upgrade-map-to-d7 document which shows me how much this proposed change will affect our http://drupal.org/community-initiatives/drupalorg/drupal7 initiative.

1. Does the gravatar.module upgrade path work flawlessly with our current d.o user accounts?
2. How much effort will need to go into theming new D6 pictures sitewide, and how much time will that increase the D7 Bluecheese theming effort?
3. How many D6 imagecache presets will we need, and do they all upgrade themselves perfectly into D7 without errors?
4. What does the "User can opt-out so that no image is displayed (see issue summary above)" workflow look like, and will it be different in d6 and d7? Will they be able to opt-out as they sign up with our site, or will they have to come back and disable their newly auto-added picture later by editing their account?

Clarifying the title as belonging to www.drupal.org and not all sub-sites.

...added ImageCache Profiles contrib project to the related projects and updated/moved things here and there.

Changing the title back because as per #59 -
"This issue needs to be about making user pictures available on all sites."

User pictures won't be turned on only on drupal.org but on sub-sites as well.
As discussed today during Drupal.org office hours - problem of uploading picture once and then showing it on all sub-sites is the main blocker for this issue.

It won't be possible to do it via Bakery in Drupal 7. So we need to use data sharing mechanism, which is in work in this issue: #1296176: Use Association Membership information via JSON and use it for all profile info from Drupal.org, including profile pictures.

Adding a 'postponed' comment to the summary.

+1 Gravatar. Make life easy for now.

This will have to wait for D7.

I is very easy to create gravatar-like service (without gravatar) from any drupal site, for example I use this code to achive it (avatar based on user_id and not on email) very handy for any drupal multisite with common user table:

function ok_avatar_menu() {

  $items['userpic/%/%'] = array(
    'page callback' => 'ok_avatar_arguments',
    'page arguments' => array(1, 2),
    'access arguments' => array('access content'),
    'type' => MENU_CALLBACK,
  );

  return $items;
}


function ok_avatar_arguments($uid, $size) {

  // Make sure you don't trust the URL to be safe! Always check for exploits.
  if (!is_numeric($uid) || !is_numeric($size)) {
    // We will just show a standard "access denied" page in this case.
    drupal_access_denied();
    return;  // We actually don't get here.
  }
//todo check http://drupal.org/node/145279 http://api.drupal.org/api/drupal/includes%21cache.inc/function/cache_set/7 to use static cache
if (!cache_get($uid . 'ok_avatar_cache' . $size)) {
    $account = user_load($uid);
  $avatarsize = array(1=>'thumbnail',2=>'medium',3=>'large',4=>'32x32');
 
  //pls create and put to /pictures folder deafault image : default.png	
  //todo: put default avatar to module folder $base_url . '/' . drupal_get_path('module', 'ok_avatar') . '/default.png'
  $uri = isset($account->picture->uri) ? $account->picture->uri : 'public://pictures/anonim.jpg';
	
  $url = image_style_url($avatarsize[$size], $uri);//do all your time taking complex calculations here
  cache_set($uid . 'ok_avatar_cache' . $size, $url, 'cache', 60 * 60); //stores in cache table 1 hour
    
  } else {
    $return = cache_get($uid . 'ok_avatar_cache' . $size);
    $url = $return->data;
  }
  $extList = array();
  $extList['gif'] = 'image/gif';
  $extList['jpg'] = 'image/jpeg';
  $extList['jpeg'] = 'image/jpeg';
  $extList['png'] = 'image/png'; 
  
  
  $imageInfo = pathinfo($url);
  $ext = isset($imageInfo['extension']) ? $imageInfo['extension'] : NULL;
  $contentType = 'Content-type: ' . $ext;
  
  header("Cache-Control: max-age=3600"); //stores in cache 1 hour
  header ($contentType);
  
  readfile($url); 
}

this is one of the way, an there are a lot more like using http://drupal.org/project/imagecache_external

adding blocker issue

Well, Drupal.org is upgraded to D7. There are other ways to do this of course, but it seems like https://drupal.org/project/gravatar will probably hit a lot of users the fastest. There are a million users now, so finding a way to simplify it for users would be good.

Having images on comments & posts would make it feel more like a community.

So drupal.org shall run a service that requires users to create a wordpress account?

I think the Gravatar solution is dead.

edit: My snappy tone isn't direct @mgifford but a result of my frustration with Gravatar as such.

Understandable.. So back to #72?

The gravatar module lets users upload a local picture and uses that by default. It just uses gravatar.com to show pictures for folks who prefer not to upload locally. And you can even disable your gravatar image in your profile if you don't want your public gravatar image being shown on a given Drupal site. I think all the bases are covered here.

BTW when I last looked at the MD5 hashes of all groups.drupal.org account, there was a significant chunk of users that had Gravatars already. Gihub even uses Gravatars, but lets you specify which email address to use when looking it up.

The summary of this issue is quite good. The first step is to just enable registered users to upload an image and use it as their profile avatar.

That's pretty trivial. Why don't we start there (this week even)?

We can then confirm how we want this to be placed and what the impacts will be for performance and what not.

Given that there are a million users, I do think we need to define a default image or behavior when a user hasn't uploaded an image. There will probably be a lot that never do.

If folks have provided a Twitter or Google+ account we can suggest that they use the image that they have there. This would help facilitate more folks uploading images. It could just be suggested in /user/UID/edit when someone goes there and doesn't have an image selected.

https://dev.twitter.com/docs/api/1.1/get/users/show
https://developers.google.com/+/api/latest/people/get

If they don't have either of those, then it seems pretty trivial to fall back to using gravatar:
https://en.gravatar.com/site/implement/images/php/

Those are details that we can work out later. The first step is enabling photos with user accounts, so let's get on with that.

The screenshots are well worth looking at. Mark's done an amazing job!

I've now gone through most of the issues in the https://groups.drupal.org/prairie-initiative group.

I do think that adding this will help make our community stronger.

Is there any way I can help out w/ this?

The rough todo list is:

• Write a script to move groups.drupal.org user pictures into place for Drupal.org. This can be done with the users.init column in groups's database. The query should output mv commands that can be run on our media server.
• Make an a child issue for user picture styling of #936304: [META] Style issue comments and implement. We should have them for all comments, not just the issue queue.
• Use #556666: Sync hooks: Enable sharing of arbitrary data to implement pushing the user pictures out to subsites. All we really need to sync is whether a picture exists or not, the sub site has the master site's uid, so it can construct the URL in the drupalorg_crosssite module.
• Update this issue's summary.

https://drumm-drupal.redesign.devdrupal.org/user/3064 is an example page with a user picture.

The page layout is based on some work Dani Nordin has been doing for the DSWG Community tools team. There is more to come, it is in the design phase right now.

I've also updated bakery on all Drupal.org sites on D7, which will allow sharing user pictures across sites.

Nice improvement for the profile page. Great to see that bakery is updated to allow images.

I hope at some point after this lands we'll reconsider allowing Gravatars for people that want to use them. I don't want to have Drupal.org be yet-another-site-that-makes-me-upload-my-avatar.

The basic support for profile pictures has been turned on. I'm importing pictures from DrupalCon Austin with:

$result = db_query("SELECT substring_index(substr(u.init, 17), '/', 1) uid, f.uri FROM users u INNER JOIN file_managed f ON f.fid = u.picture");
$rows = array();
foreach ($result as $row) {
  $row->uri = file_create_url($row->uri);
  $rows[] = $row;
}
print_r(serialize($rows));

and on the Drupal.org side:

$data = unserialize(file_get_contents('/home/drumm/foo'));

foreach ($data as $row) {
  $account = user_load($row->uid);
  if (empty($account->picture)) {
    $image = drupal_http_request($row->uri);
    if (!isset($image->error)) {
      print $account->uid . "\n";
      $file = file_save_data($image->data);
      $file->status = FALSE;
      $account->picture = $file;
      user_save($account);
    }
  }
}

Still to do:

• Show pictures on comments.
• Import pictures from other Drupal.org sites.
• Set up syncing across sites, so Drupal.org will never ask you to upload another picture.

Great to see my photo from https://austin2014.drupal.org/users/mgifford

Now show up https://drupal.org/user/27930

Are we going to have new issues for the pictures on comments? The other two I can see as being related.

This is now on staging sites, like https://staging.devdrupal.org/node/2224917, for testing.

Can we also add default userpic for people who don't have any. There is one in Bluecheese's images folder.

User pictures are now squared off and there is a default picture.

Now deployed.

Horray!

Wow, this change actually looks really hot. Thanks so much for everyone's work on this!! Yay for no longer being anonymous blue nicknames. :)

Very very quietly, just because I am that guy: I remember a time when being anonymous blue nicknames were considered an advantage -- being equal in gender, age and who knows what else. Now there's an actual pressure to de-anonymize yourself.

Now there's an actual pressure to de-anonymize yourself...

Indeed.

When we had a brief discussion of this on IRC someone:

I already got an email saying my icon was "cute" :(

"Why you don't have an avatar?" even if not explicitly asked the pressure is present.

Avatars also pressure people to behave more like human beings. It's much easier to treat de-humanized little blue names like garbage, and much harder when you see the cute picture of their adorable cat.

So given that people can easily upload avatars that simply say "I don't need no steeeenkin' avatar!" (in tiny, tiny font) I think the pressure some might feel is an acceptable trade-off for the benefits we gain community-wise.

Avatars also pressure people to behave more like human beings. It's much easier to treat de-humanized little blue names like garbage, and much harder when you see the cute picture of their adorable cat.

Hmm, I've put the avatars into my blocklist as I regard them as visual clutter. Guess that surprises nobody. :D

Thanks for the work on this, I like it!

I've also noticed that we aren't using image styles correctly for these comments. The images are around 512px * 512px and they are getting resized in CSS down to 40 * 40!

That's a lot of additional kilobytes, especially on those mega issues with hundreds of comments. They were hard enough to load on a mobile phone as it was. Does it make sense to fix it here? Feels pretty major.

Thanks again.

Ah I did take a screenshot, I just forgot to upload it. Is this just a caching problem?

I'm definitely still seeing user pictures as large versions getting scaled down with CSS, even on this issue right now.
300x300: https://drupal.org/files/styles/drupalorg_user_picture/public/user-pictu...
512x510: https://drupal.org/files/styles/drupalorg_user_picture/public/user-pictu...

The pictures are 80x80 for high-resolution devices. (Using the new picture element would be cool, but extra work and the 80x80 images are already relatively small.)

I corrected these by running:

$path = '/var/www/drupal.org/htdocs/files/styles/drupalorg_user_picture/public/user-pictures';
$d = dir($path);
while (FALSE !== ($entry = $d->read())) {
  list($width, $height) = getimagesize($path . '/' . $entry);
  if ($width > 80 || $height > 80) {
    preg_match('#-(\d+)-#', $entry, $match);
    list(, $uid) = $match;
    $account = user_load($uid);
    $derivative_uri = image_style_path('drupalorg_user_picture', $account->picture->uri);
    file_unmanaged_delete($derivative_uri);
    image_style_create_derivative(image_style_load('drupalorg_user_picture'), $account->picture->uri, $derivative_uri);
  }
}
$d->close();

Either some code I wrote for migrations from DrupalCon sites was calling image_style_create_derivative() incorrectly and/or the image preset cache was temporarily incorrect. When either happens, the original image gets copied over.

The humanizing effect of having pictures is legit. However, there is definitely pressure to have an icon. I got crap from all kinds of people for YEARS for not having a non-egg picture on Twitter. (And I'm not someone who has any reason to not have my picture and name associated.) That did stop when I switched to the Garfield icon, which looks nothing like me aside from the vest.

So, yeah. It's a trade-off. I don't know which way it will go at this point. I guess we'll find out.

One problem: I am fine with my picture on DrupalCon sites, but I'm sorely tempted to remove it from d.o. I haven't checked to see if that's possible yet.

wondering if we should have a selection of generic drupal-related icons users can choose from...

@silverwing can we spin that off into a follow-up issue? There are so many drupal icon variations to draw on. Would be a great wealth of goofy icons we should already be able to draw on.

Also, you'd suggested on Twitter, "Now the user System Message needs a kick ass icon!" - Agreed!

@Crell Definitely agree that this should be possible. Not everyone wants their photo used everywhere. We can't all use a great Garfield icon.

Mind you they seem different in GDO so maybe it was just pulled once with Austin to ensure that there was a solid seeding of icons going forward.

@killes@www.drop.org No harm in that. At one point we might want to offer this as an option in the user profiles. Your solution is easier though.

I am a bit confused why this hasn't been a problem on GDO... Or maybe it has, but not sure where that thread would be.

I think that some sort of identicon-thing would be a big improvement over a gray silhouette.

created #2276087: Allow for a selection of user avatars

Also had #2275911: Give System User its own user picture which was shot down - if System Message isn't going to have its user name linked in issues, then there's no reason to visit its page. :(

Avatars also pressure people to behave more like human beings.

Not that I've witnessed in any social network, e.g. Youtube.

In any case it is visual clutter and not needed in issues, I have removed them using QuickStyle.

Re removing pictures migrated from DrupalCon sites: sure, go ahead and remove / change if you want. The basic picture uploading is basic Drupal core.

I didn't migrate pictures from groups.drupal.org because they are only 85x85. Our max is now 1024x1024, hopefully enough pixels for various sizes we want for a few years. Scaling to 80x80 used on comments wouldn't be ideal. And syncing back to groups.drupal.org will be harder since it is on D6.

@drumm - I hadn't understood that anyone wanted to roll back the image import you'd done.

I think there was uncertainty about whether the images on d.o were synced with *.d.o images. From what I understand this was only done once to seed the issue queues, so no problem. If @Crell's able to throw up Garfield here & his photos on the DrupalCon sites I think that would address his concerns.

Maybe at some point we could facilitate a way to either push out new photos when they are changed on drupal.org, but that definitely should be a new issue.

There's been lots of positive feedback from folks about this move (especially on twitter). It will be interesting to try to figure out what the impact of it is in 3 months time. Not sure how to isolate this change from it's environment. Without A/B testing infrastructure in place it is really hard to know.

Btw, I posted this blog post looking at this issue as well as the past/future ideas for shaping community involvement https://openconcept.ca/blog/mgifford/building-community-drupalorg

related: #2287765: [No patch] Think about profiling, discrimination and harassment implications of user pictures/icons