Closed Bug 648948 Opened 14 years ago Closed 14 years ago

Make a visual indicator of new contributors

Categories

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

Product:
bugzilla.mozilla.org
Component:
General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: paul.biggar, Assigned: glob)

References

Details

(Whiteboard: [contrib-engagement])

Attachments

(2 files, 4 obsolete files)

screenshot
6.06 KB, image/png
Details
TagNewUsers extension, v4
3.33 KB, patch
dkl
: review+
Details | Diff | Splinter Review
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/ )
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.
OS: Mac OS X → All
Hardware: x86 → All
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...
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)?
Or perhaps we should ask somebody with UX experience about this.
(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: nobody → glob
Attached 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?
note: this indicator is only show to users in the can-confirm group.
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
(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.
(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.
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).
(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 :)
(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.
> 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
Attached image screenshot —
updated screenshot
Attachment #525318 - Attachment is obsolete: true
Attached 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.
(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.
(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?
(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.
(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+
Attached 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+
Attached 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)
(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-
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+
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
Closed: 14 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.

Attachment

General

Creator:
Created:
Updated:
Size: