Make a visual indicator of new contributors

RESOLVED FIXED

Status

()

--
enhancement
RESOLVED FIXED
8 years ago
2 years ago

People

(Reporter: paul.biggar, Assigned: glob)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [contrib-engagement])

Attachments

(2 attachments, 4 obsolete attachments)

(Reporter)

Description

8 years ago
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.
This seems like it would be best as a mozilla.org-specific feature.
Assignee: create-and-change → nobody
Component: Creating/Changing Bugs → Bugzilla: Other b.m.o Issues
Product: Bugzilla → mozilla.org
QA Contact: default-qa → other-bmo-issues
Version: unspecified → other
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/ )
(Reporter)

Comment 3

8 years ago
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.

Updated

8 years ago
OS: Mac OS X → All
Hardware: x86 → All

Comment 4

8 years ago
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...
(Reporter)

Comment 5

8 years ago
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)?
(Reporter)

Comment 6

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

Comment 7

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

Amen!
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.
Severity: normal → enhancement
(Assignee)

Updated

8 years ago
Assignee: nobody → glob
(Assignee)

Comment 9

8 years ago
Posted image screenshot (obsolete) —
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?
(Assignee)

Comment 10

8 years ago
note: this indicator is only show to users in the can-confirm group.
(Reporter)

Comment 11

8 years ago
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!!
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
(Reporter)

Comment 13

8 years ago
(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.
(Assignee)

Comment 14

8 years ago
(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).
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.
(Reporter)

Comment 16

8 years ago
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).
(Assignee)

Comment 17

8 years ago
(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

8 years ago
(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.
(Assignee)

Comment 19

8 years ago
> 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.
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!).
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! :-)
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
(Assignee)

Comment 23

8 years ago
Posted image screenshot
updated screenshot
Attachment #525318 - Attachment is obsolete: true
(Assignee)

Comment 24

8 years ago
Posted patch TagNewUsers extension, v1 (obsolete) — Splinter Review
Attachment #526036 - Flags: review?(dkl)
(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.
(Reporter)

Comment 26

8 years ago
(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?
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.
(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.
(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.
(Assignee)

Comment 30

8 years ago
(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?
(Assignee)

Comment 31

8 years ago
(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.
(Reporter)

Comment 32

8 years ago
(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 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
Attachment #526036 - Flags: review?(dkl) → review+
(Assignee)

Comment 34

8 years ago
Posted patch TagNewUsers extension, v2 (obsolete) — Splinter Review
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).
Attachment #526036 - Attachment is obsolete: true
Attachment #526664 - Flags: review+
(Assignee)

Comment 35

8 years ago
Posted patch TagNewUsers extension, v3 (obsolete) — Splinter Review
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.
Attachment #526664 - Attachment is obsolete: true
Attachment #526696 - Flags: review?(dkl)
(Assignee)

Comment 36

8 years ago
(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
(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 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
Attachment #526696 - Flags: review?(dkl) → review-
(Assignee)

Comment 39

8 years ago
this revision is just s/first_patch_bug/first_patch_bug_id/
Attachment #526696 - Attachment is obsolete: true
Attachment #527005 - Flags: review?(dkl)
Comment on attachment 527005 [details] [diff] [review]
TagNewUsers extension, v4

Looks good. r=dkl
Attachment #527005 - Flags: review?(dkl) → review+
(Assignee)

Comment 41

8 years ago
thanks dkl :)

Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bmo/4.0/
modified extensions/TagNewUsers/Extension.pm
modified extensions/TagNewUsers/template/en/default/hook/bug/comments-user.html.tmpl
Committed revision 7597.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Depends on: 652389
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.