One unintended side effect of Needinfo use is that comments of the form "hello I am new here may I take this bug" are frequently ignored for weeks or months. https://bugzilla.mozilla.org/show_bug.cgi?id=490255#c2 https://bugzilla.mozilla.org/show_bug.cgi?id=738221#c10 This is pretty bad. For this and a couple of related reasons, I'd like comments made by "new to bugzilla" accounts on good-first-bugs to automatically trip off the "needinfo" flag and set it to whoever's mentoring the bug. We'll be at a point where good-first-bugs must have a mentor attached to them soon, and this seems like a decent way of not having people's requests to participate get lost.

I do worry that this will get contributors in the habit of relying on this automatic behaviour and then the problem will just be deferred until their account is no longer "new to bugzilla". In order to prevent this there should also be some messaging about this happening.

That might happen, but I'll take a mentoring-for-engaged-contributors problem over a losing-potential-contributors problem every time.

(In reply to Byron Jones ‹:glob› from comment #3) > i can't help but feel this sounds like a heavy-handed approach to mentors > not reading their bugmail, and would like to consider other approaches to > this issue before spamming needinfo. It's not spam if you're signed up for it; rapid responses to mentored bugs are an expected part of being a mentor. I'm deeply reluctant to send email to fix a problem with people not reading their email. > has anything happened to determine why the comments are being missed or > ignored by the mentors? The "why" hasn't been investigated; exclusive use of needinfo is strongly suspected to be the reason, but that's not confirmed. - mhoye

(In reply to Mike Hoye [:mhoye] from comment #4) > I'm deeply reluctant to send email to fix a problem with people not reading > their email. same :) yet that's what you're asking for here :| do you have any thoughts on my alternatives from comment 3?

(In reply to Byron Jones ‹:glob› from comment #5) > > same :) yet that's what you're asking for here :| Yeah, but this will also show up on their bugzilla dashboards (and presumably flagged in their existing email systems....) We've already got a mentored-bug email header to filter on, but it's not widely used. I've got to evangelize that better, and hopefully in the meantime this will work too.

(In reply to Matthew N. [:MattN] from comment #1) > I do worry that this will get contributors in the habit of relying on this > automatic behaviour and then the problem will just be deferred until their > account is no longer "new to bugzilla". In order to prevent this there > should also be some messaging about this happening. FWIW, I support the original proposal, because I want to make [mentor=] a real part of the system, and this is a nice tie-in. The behaviour you're describing is what I would call emergent, in the sense that it might emerge, or it might not. If it does emerge, it's at least biting folks who've already established a presence as contributors, and hopefully know how to get help and may even have a mentoring relationship established; as opposed to biting new folks who have no touch points.

(In reply to Byron Jones ‹:glob› from comment #5) > (In reply to Mike Hoye [:mhoye] from comment #4) > > I'm deeply reluctant to send email to fix a problem with people not reading > > their email. > > same :) yet that's what you're asking for here :| > > do you have any thoughts on my alternatives from comment 3? Yeah, I think a combination of things would be a good approach. I propose that the needinfo flag is set for the first of mentor or owner that's set, and that whether or not there's somebody there to send an email to that some email goes to getstarted@mozilla.org (my community-engagement email.)

OK, having received some feedback that amounts to "I have no idea what you just said", let me try that again. My goal here is to not have early contribution efforts and new-to-bugzilla inquiries fall off the radar inadvertently. We know that the abandonment/dropoff rate for first time contributors is quite high, but we know also that once we've got somebody past the first four or five contributions we're quite likely to see a seventh or eighth. So small efforts to move the early arc of that curve in a positive direction are expected to pay off handsomely over the long term. We also know that getting back to interested contributors, or replying to first-time patch review requests within 2 days is strongly correlated with followup contributions, and that contributors whose patches get no reply within a week are unlikely to submit another. So here's what I propose: Whenever a "new to bugzilla" contributor makes a comment or attaches a patch, that: - If a bug has a mentor, that mentor is automatically needinfo'ed on the bug. - Otherwise, if the mentor is not set but the bug has an owner, the owner is NI'ed. - If neither one is set, nobody is needinfo'ed, but - In either case, getstarted@mozilla.org gets an email so that I can look into it myself. Also I should stop trying to comment on bugs when I'm half asleep. I'll file a bug about that later tonight, I guess.

The automation tools team has a dashboard that looks for questions from contributors. It is not the same, as this issue, but the dashboard could be extended to include this rule. The dashboard could also be expanded for other teams, if desired. Our next contributor meeting is July 21 (tomorrow) at 15:30 in the Ateam Vidyo room. For others reading this, our team can be found on #ateam on irc.mozilla.org [1] http://people.mozilla.org/~klahnakoski/contributors/dashboard.html#

This would have helped several times in the last month with Treeherder's mentored bugs (I normally have to keep track and needinfo the mentor).

Mike, I want to pick this one up. Are you willing to mentor me on this one because I am fairly new to the community? Thanks

I would like to, but I'm not the right person for that - you'd definitely want somebody more familiar with the codebase. Let me ask around! I'd be glad to have this one wrapped up.

(In reply to Divyansh Sharma [:spiro] from comment #13) > Mike, > > I want to pick this one up. Are you willing to mentor me on this one because > I am fairly new to the community? > > Thanks I can help mentor this. Are you comfortable setting up a development VM using vagrant? The repo is https://github.com/mozilla-bteam/bmo

Hi Dylan, Thanks for mentoring this! I have set up VM using vagrant. What should I do next?

Let's get this rolling. This is easily two separate PRs: 1. Add 'is_new' to the BUGZILLA.user object (as part of the TagNewUsers extension) 2. When the comment field is edited and the (added in the previous PR) BUGZILLA.user.is_new is true, check the needinfo checkbox and choose the "mentor" option of $("#needinfo_role") So for the first one, you'll add a file extensions/TagNewUsers/template/en/default/hook/global/header-start.html.tmpl, something like extensions/EditComments/template/en/default/hook/global/header-start.html.tmpl. In this case you'll just set js_BUGZILLA.user.is_new For the second one, you'll probably be good just adding the code to bug_modal.js.

I'd like to be able to search bugs filed by new users, so will we need a separate bug to do that, and report back .is_new in search results?

(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #18) > I'd like to be able to search bugs filed by new users, so will we need a > separate bug to do that, and report back .is_new in search results? is_new is synthetic based on the oldest comment of the user and their creation timestamp. We could add a join to Bugzilla::Search based on the `profile.creation_ts` but that would be a different bug.

Dylan I have created PR, can you have a look at it and suggest changes (if needed)? https://github.com/mozilla-bteam/bmo/pull/988 Thanks