<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>If you don't have good first bugs in your component and would like one, consider removing expired Telemetry probes! They have a real compile-time and runtime memory hit of literally dozens to hundreds of bytes, so their removal is not just a clean-up task: It's Quantum Performant!</div><div><br></div><div>I wrote an email on how to do this back in 2017[1], but let's update it for 2019 shall we?</div><div><br></div><div>Step 1) Skim through the list of probes that are expired in Firefox 68[2] for one or more that are related to your component.<br></div><div>Step 2) Verify that they are still present in the tree by looking at Histograms.json[3], Scalars.yaml[4], or Events.yaml[5] (based on the kind of probe)<br></div><div>Step 3) File a bug in your component to have it removed. You might find our template for mentored bugs[6] handy, or you might not. You should ensure that you put a mentor in the Mentors field, and that there is a whiteboard tag something like [good first bug][lang=js] so that it'll show up in places like Codetribute[7] (by the way, codetribute is awesome)<br></div><div><br></div><div>That's all it takes to have another good first bug in your component!<br></div><div><br></div><div>:chutten<br></div><div><br></div><div>[1]: <a href="https://mail.mozilla.org/pipermail/firefox-dev/2017-March/005237.html">https://mail.mozilla.org/pipermail/firefox-dev/2017-March/005237.html</a></div><div>[2]: <a href="https://telemetry.mozilla.org/probe-dictionary/?channel=nightly&constraint=is_expired&version=68">https://telemetry.mozilla.org/probe-dictionary/?channel=nightly&constraint=is_expired&version=68</a></div><div>[3]: <a href="https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Histograms.json">https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Histograms.json</a></div><div>[4]: <a href="https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Scalars.yaml">https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Scalars.yaml</a></div><div>[5]: <a href="https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Events.yaml">https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Events.yaml</a></div><div>[6]: <a href="https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/internals/mentored-bugs.html">https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/internals/mentored-bugs.html</a><br></div><div>[7]: <a href="https://codetribute.mozilla.org/projects/internals">https://codetribute.mozilla.org/projects/internals</a><br></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 19, 2019 at 7:55 AM Florian Quèze <<a href="mailto:florian@queze.net">florian@queze.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Mar 19, 2019 at 10:37 AM Mark Banner <<a href="mailto:mbanner@mozilla.com" target="_blank">mbanner@mozilla.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 19/03/2019 08:41, Patrick Brosset wrote:<br>
> Interestingly, the DevTools team was discussing this specific point a <br>
> week or 2 ago, and decided the do the exact opposite:<br>
> assigning the good-first-bug as soon as someone claims it, so as to <br>
> "secure" it and avoid people working on the same thing at the same time.<br>
<br>
I've also been doing the same for a long time now. I have to admit, I've <br>
never really understood the free-for-all until first patch approach. <br>
Whilst I can see it might be simpler, in that someone has at least <br>
posted a patch, it seems to be contrary to our normal processes, where <br>
we assign bugs to ourselves to indicate that we're working on them, so <br>
that we don't have work duplicated.<br></blockquote><div><br></div><div>The intent here is to avoid blocking mentored bugs for people who just say "Hi, I would like to work on this bug, can you assign it to me?" and then disappear (this case is unfortunately very common). So I think "do not assign them to the bug until a patch is attached" is a simplification, and what we really want is to avoid assigning bugs to people who haven't proved actual interest in the bug. Attaching a patch for review is what gives the strongest signal of interest, but other ways to show interest, like asking questions in the bug or on IRC that show the contrbutor has at least read the bug description and wants help about how to get started are also valid. I would recommend not assigning bugs to people who have just typed (or even copy pasted) a very generic comment.<br></div></div><br>-- <br><div dir="ltr" class="gmail-m_8809057373203362798gmail_signature">Florian Quèze</div></div>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</blockquote></div>