648948 - Make a visual indicator of new contributors

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, enhancement)

Description

[Paul Biggar]

In general, new contributors should be handled with kid-gloves, not with the battle-worn voices in which old contributors address each other. However, it's pretty difficult to figure out if a contributor is new. I'd like some visual notification of this on the show_bug.cgi screen.

Suggestions:

 - light green (or whatever) background to their names if they have been a bugzilla member for less than 60 days (or 100 bug comments, or some similar metric)

 - simply make user names link to a search for anything that user has done (except CC). Then we are one click from seeing how many bugs a contributor is active in, which will show us if they are new.

Comment 1

[Max Kanat-Alexander]

This seems like it would be best as a mozilla.org-specific feature.

Comment 2

[Max Kanat-Alexander]

I think there may be a duplicate of this bug, by the way--we had this discussion with David Eaves a while back too, as I recall. ( http://eaves.ca/2010/07/20/some-thoughts-on-improving-bugzilla/ )

Comment 3

[Paul Biggar]

Just to be clear, how do we go about fixing this?

I personally consider this to be the highest priority bug I've ever filed.

Comment 4

[(no longer active)]

It would probably be a good idea to show this only to experienced users (like, those with editbugs), because I'd hate this to come across as Mozilla somehow discriminating against the new users...

Comment 5

[Paul Biggar]

We certainly dont want to come across as discriminating, but I'm not sure that's the right way. Perhaps if the visual indicator was a small red heart (because we love new contributors)?

Comment 6

[Paul Biggar]

Or perhaps we should ask somebody with UX experience about this.

Comment 7

[(no longer active)]

(In reply to comment #6)
> Or perhaps we should ask somebody with UX experience about this.

Amen!

Comment 8

[Max Kanat-Alexander]

Paul: The way to get this implemented is to have dkl or glob write an extension and then get it on a deployment plan for after bmo-4.0 gets rolled out.

Comment 9

[:glob ✱]

Attachment: screenshot

i've thrown together a POC extension which implements this.

it'll show the new tag (see attached screenshot) for users that don't have can-confirm, are newer than 60 days old, and have made less than 25 comments.

paul, is this what you had in mind?

Comment 10

[:glob ✱]

note: this indicator is only show to users in the can-confirm group.

Comment 11

[Paul Biggar]

I suggest a minor tweak:

  (!can-confirm) AND (less_than_60_days OR less_than_25_comments)


But can I just say how awesome you are for doing this so quickly!!

Comment 12

[Gervase Markham [:gerv]]

Can you quickly check the performance on the query you are using for less_than_25_comments? This query is going to be run quite a lot.

Paul: if we adopt your logic, then someone who has been on Bugzilla, perhaps lurking, for 5 years, making the occasional comment, will still be marked as "new". I think we'd either need to use a different indicator ("inexperienced"? :-) or keep the current logic.

Gerv

Comment 13

[Paul Biggar]

(In reply to comment #12) 
> Paul: if we adopt your logic, then someone who has been on Bugzilla, perhaps
> lurking, for 5 years, making the occasional comment, will still be marked as
> "new".

Yes, that was the intention. Remember that this isn't a slight, it's a visual queue to experienced contributors to be a little kinder. False positives are better than false negatives.

Comment 14

[:glob ✱]

(In reply to comment #12)
> Can you quickly check the performance on the query you are using for
> less_than_25_comments? This query is going to be run quite a lot.

my proof-of-concept just does
  SELECT COUNT(*) FROM longdescs WHERE who=?
while there's a covering index, it's probably limiting for performance reasons.

for the real extension, i'm thinking of adding a comment-count column to the profiles table and the user object.  ditto for age (this currently requires a look-up from the profiles_activity table to grab the creation_ts).

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

Red tends to be a color associated with alarm and danger.  Perhaps green instead?
Though I'll admit that I like the heart motif suggested by Paul.  

Using the verbiage "new to bugzilla" instead of "new" would have the advantage of offering a bit more clarity.

Comment 16

[Paul Biggar]

Once this goes up, are we in a position to iterate on it quickly, or do we need to get it 100% correct now?

Either way, I agree with the "new to bugzilla" wording and the green (and of course my own suggstion of a small red heart).

Comment 17

[:glob ✱]

(In reply to comment #16)
> Once this goes up, are we in a position to iterate on it quickly, or do we need
> to get it 100% correct now?

we don't need to get it 100% correct now.

> Either way, I agree with the "new to bugzilla" wording and the green (and of
> course my own suggstion of a small red heart).

a green 'new to bugzilla' label makes sense, i'll change it to that.

i'm not a fan of also adding a heart image.  if it's added along with the text, it doesn't provide any new information, only clutter.  if it's added instead of the text, the message we're trying to convey isn't clear at all from a heart image -- using an image of love doesn't immediately mean "please take into consideration that i'm new here".  and we don't love contributors any less once they get can-confirm :)

Comment 18

[(no longer active)]

(In reply to comment #16)
> Once this goes up, are we in a position to iterate on it quickly, or do we need
> to get it 100% correct now?

If I could get access to the data for each username in an efficient way, I could integrate this into Bugzilla Tweaks tomorrow, and we would be able to iterate on the UI quite easily.

Comment 19

[:glob ✱]

> If I could get access to the data for each username in an efficient way

unfortunately that's the hard part :)

the bugzilla staging environments are running with a sanitized copy of the bmo database, and i can push updates to them pretty quickly, so this shouldn't be a problem.

Comment 20

[Alex Faaborg [:faaborg] (Firefox UX)]

We should reference new with a directly positive connotation, like (new!) in green.  Using red, or anything else potentially negative creates an atmosphere were new contributors potentially aren't cast as welcome, trusted, or as useful as existing contributors.  This isn't true, they just haven't had a chance to prove themselves yet.  It's really important to our overall growth that new contributors feel respected and appreciated.

Frankly I wouldn't mind swapping out or existing contributors for a new set (kidding!).

Comment 21

[Ed Morley [:emorley]]

Paul, was this bug aimed just at people new to bugzilla or also people new in the [good first bug] sense?

As someone who has received lots of guidance/encouragement from people (yourself included!) over the course of the last week (to get me from checking out m-c for the first time, through to writing my first patch) - I know how much of a difference the extra help/personal touch can make for people wanting to contribute a patch; and most importantly whether they enjoyed the process enough to want to repeat it.

However, in my case I didn't meet the following criteria:
> (!can-confirm) AND (less_than_60_days OR less_than_25_comments)

...so wouldn't have been marked new, even though I was new to contributing (in the patch sense) side of things. 

Marking people as "new to bugzilla" is a great idea; I'm just wondering if it's also possible to cater for the "new to contributing" group as well - or at least separate out people with say hg level 3, editbugs & 300 patches to their name, from those who are just starting out. 

How about:

1) [As Paul's sugestion] People are marked "(New to bugzilla)" (font green) if:
(!can-confirm or higher) AND (less_than_60_days OR less_than_25_comments)

2) If the user has editbugs or canconfirm, they get an icon reflecting which level (similar to the bugzilla-reviewers icon).

3) If the user works for MoCo (would basing this off of the moco-confidential permissions group work?); adding "(Mozilla Corporation)" (font colour say purple or at least something other than the green of "new to bugzilla").

4) If the user has commit access, then an icon shown, depicting level 1, 2 or 3 as appropriate. It would mean that experienced community members would know whether they need to offer to push to tryserver, or say knowing if they need to tell the user to set checkin-needed and so on. Now obviously this would require some kind of integrating into LDAP/hg ssh keys; so not sure how realistic. If this wasn't possible, then perhaps some icon based upon if that user has attached a patch before and if so, how many (or else number of bugs where they were the assignee).


The end result would be something like...

Joe Bloggs (New to bugzilla)

Joe Bloggs {{canconfirm_icon}}

Joe Bloggs {{editbugs_icon}} {{hg_lvl_1_icon}}

Joe Bloggs {{editbugs_icon}} {{hg_lvl_3_icon}} (Mozilla Corporation)

...etc

If the number of icons were deemed too much; then perhaps some of the clutter could be reduced by adjusting the user's name font colour to reflect editbugs/canconfirm status (ie phpbb admin vs moderator vs normal user style).

Anyway, sorry for the verbose reply; but like Paul I think this is an area that could make a big difference to new contributor retention.

Thanks! :-)

Comment 22

[Gervase Markham [:gerv]]

Hi Ed,

1) is, as I think we all agree, a great idea.

I'm not sure there's much value in 2) - what do you think people would do differently based on it?

3) is, I'm afraid, an idea straight from the pit of doom and misery. People's employment status, as opposed to their capabilities and the time they have available, should not be a driver of _anything_ in the Mozilla project. We want to minimise focus on this, not increase it.

4) Bugzilla doesn't have that information, I'm afraid.

Gerv

Comment 23

[:glob ✱]

Attachment: screenshot

updated screenshot

Comment 24

[:glob ✱]

Attachment: TagNewUsers extension, v1

Comment 25

[Ed Morley [:emorley]]

(In reply to comment #22)
> I'm not sure there's much value in 2) - what do you think people would do
> differently based on it?

If only the "new to bugzilla" part is implemented, it still leaves a large gap between a user who has 25 comments and someone who is an experienced patch contributor.

Whether the canconfirm/editbugs perms are the best way to add additional hierarchies; I don't know. (I just thought it would have a lower search query performance hit than searching by number of patches that the user has attached).

I'm just trying to find a way to cover scenarios like (my own):
  * User opened a BMO account ages ago to file one bug (but hadn't really used it since); so it's >60 days old.
  * That user starts commenting on bugs, eg trying to help triage newly filed UNCOs; so now has more than 25 comments.

-> The user is now no longer marked as "new" and instead shows up exactly the same as someone who has contributed 300 patches and has commit access.

However this user would still benefit from things like:
  * People looking out for things like r?(nobody)
  * People offering to push to try since it's unlikely the person has access themselves
  * Review denied requests being sugar coated more than usual, to ensure the user isn't dispirited and gets through their first few patches to build confidence
  * Review granted requests being accompanied with a "you'll now need to set the checkin-needed keyword" reply; since not all reviewers set the keyword themselves and it would be a shame for the user's first patch to just sit there are bit rot without the user knowing why

How about...

* Paul's proposal:
  (!can-confirm) AND (less_than_60_days OR less_than_25_comments)
  -> "(New to bugzilla)"

* But also:
  (!new_to_bugzilla) AND (more_than_5_patches_attached_by_them)
  -> Some indication that the user doesn't need a helping hand through the patch/review/checkin-needed process any more. ie: some kind of icon representing "has contributed more than 5 patches".

This would give...

* Complete newbie:
   -> Joe Bloggs (New to bugzilla)
* New to contributing patches:
   -> Joe Bloggs
* Has contributed 5+ patches, doesn't need the extra help:
   -> Joe Bloggs {P}

What do you think?


> employment status, as opposed to their capabilities and the time they have
> available, should not be a driver of _anything_ in the Mozilla project. We want
> to minimise focus on this, not increase it.

Yeah in hindsight, good point. I only included this having seen a few people append a similar string onto their BMO nickname.

Comment 26

[Paul Biggar]

(In reply to comment #25)

I think Ed is right, we don't have quite the perfect equation. My thinking is that false positives are fine, but false negatives are bad, so maybe scale this up a bit:

(!can-confirm) AND (less_than_60_days OR less_than_100_comments OR less_than_20_attachments)


> having seen a few people
> append a similar string onto their BMO nickname.

Oh, that's not good. Can you email me privately who that was and I can think about what to do here?

Comment 27

[Josh Matthews [:jdm]]

I've never felt that adding (Mozilla Corporation) onto someone's name is a bad thing.  It does make it easier for certain folks' statements to be taken as gospel truth in bugs, which has its advantages.

Comment 28

[David Lawrence [:dkl]]

(In reply to comment #27)
> I've never felt that adding (Mozilla Corporation) onto someone's name is a bad
> thing.  It does make it easier for certain folks' statements to be taken as
> gospel truth in bugs, which has its advantages.

As long as a user is logged in they can hover over someones name and see the @mozilla.(org|com) which I think should be sufficient without adding more to the UI.

Comment 29

[Max Kanat-Alexander]

(In reply to comment #28)
> As long as a user is logged in they can hover over someones name and see the
> @mozilla.(org|com) which I think should be sufficient without adding more to
> the UI.

  Not everybody is logged in, and I personally don't want to hover everybody's name to understand who they are.

Comment 30

[:glob ✱]

(In reply to comment #26)
> (!can-confirm) AND (less_than_60_days OR less_than_100_comments OR
> less_than_20_attachments)

i don't think the attachment count is a good metric; it's really only applicable for people who contribute *code*, while age and comment count covers anyone who reports a bug.

if we were to include attachment count, it would flag 99.4% of current bmo users as new.  92.9% of accounts have never attached a file to a bug, and of those that have attached files, 92.4% have attached less than 20 files.


perhaps it would be more useful to tag a patch if it's the contributor's first?

Comment 31

[:glob ✱]

(In reply to comment #30)
> if we were to include attachment count, it would flag 99.4% of current bmo
> users as new.  92.9% of accounts have never attached a file to a bug, and of
> those that have attached files, 92.4% have attached less than 20 files.

wait, i forgot about canconfirm :)  still, i don't think it'd be a good metric.

Comment 32

[Paul Biggar]

(In reply to comment #30)
> (In reply to comment #26)
> > (!can-confirm) AND (less_than_60_days OR less_than_100_comments OR
> > less_than_20_attachments)
> 
> i don't think the attachment count is a good metric; it's really only
> applicable for people who contribute *code*, while age and comment count covers
> anyone who reports a bug.
> 
> if we were to include attachment count, it would flag 99.4% of current bmo
> users as new.  92.9% of accounts have never attached a file to a bug, and of
> those that have attached files, 92.4% have attached less than 20 files.

We must surely have 10x as many casual contributors as core contributors, so 90-ish% sounds right to me. Almost everybody outside our core contributors needs to be treated nicely to try and drag them into the fold.


> perhaps it would be more useful to tag a patch if it's the contributor's first?

That's a great idea, I love it!



Anyhow, let's go ahead with what you think is best, and we can refine it as we get feedback.

Comment 33

[David Lawrence [:dkl]]

Comment on attachment 526036 [details] [diff] [review]
TagNewUsers extension, v1

>+use constant NEW_DAY_COUNT => 60;
>+use constant NEW_COMMENT_COUNT => 25;

Add some comments explaining what each constant means and maybe remove the NEW_
as is not needed. Maybe PROFILE_AGE instead of DAY_COUNT as well.

>+    $self->{comment_count} = $count;
>+}
>+
>+#
>+#
>+#
>+
>+sub template_before_process {
>+    my ($self, $args) = @_;

Nit: put some text describing the section similar to the others.

Overall I like the implementation and looks good to me. May needs tweaks when the details
are finally ironed out in the bug comments.

r=dkl

Comment 34

[:glob ✱]

Attachment: TagNewUsers extension, v2

carrying forward r=dkl

i've committed this revision to bugzilla-stage-tip (not currently visible, give it a while).

i'm playing around with "first patch" identification, and hope to have an updated extension soonish.  i'll leave this bug open until that's in (or out, whatever the case may be).

Comment 35

[:glob ✱]

Attachment: TagNewUsers extension, v3

this revision tags a contributor's first patch.

well, it actually identifies the bug they first attach a patch too, and tags all patches by them on that bug.

Comment 36

[:glob ✱]

(In reply to comment #34)
> i've committed this revision to bugzilla-stage-tip (not currently visible, give
> it a while).

it is now functional on bugzilla-stage-tip.mozilla.org

Comment 37

[Ed Morley [:emorley]]

(In reply to comment #26)
> Oh, that's not good. Can you email me privately who that was and I can think
> about what to do here?

I can't remember specific display names (plus 1 week into contributing patches it may not the best way to make friends!). If this is something you wish to pursue, perhaps a query of the BMO DB name field for Mozilla and MoCo would be the best way forwards.

> i'm playing around with "first patch" identification, and hope to have an
> updated extension soonish.  
...
> well, it actually identifies the bug they first attach a patch too, and tags
> all patches by them on that bug.

That sounds great - thanks for your work on this Byron :-)

Comment 38

[David Lawrence [:dkl]]

Comment on attachment 526696 [details] [diff] [review]
TagNewUsers extension, v3

Nit: s/first_patch_bug/first_patch_bug_id/

I know it's longer but when I see first_patch_bug in the code I think it is the full bug object which we don't want either.

Otherwise looks good and works as expected.
r=dkl

Comment 39

[:glob ✱]

Attachment: TagNewUsers extension, v4

this revision is just s/first_patch_bug/first_patch_bug_id/

Comment 40

[David Lawrence [:dkl]]

Comment on attachment 527005 [details] [diff] [review]
TagNewUsers extension, v4

Looks good. r=dkl

Comment 41

[:glob ✱]

thanks dkl :)

Committing to: bzr+ssh://[e-mail]/bmo/4.0/
modified extensions/TagNewUsers/Extension.pm
modified extensions/TagNewUsers/template/en/default/hook/bug/comments-user.html.tmpl
Committed revision 7597.