Instead of doing something like set(['val1', 'val2']), we should do {'val1', 'val2'}.

Follow-up of #9.

We should replace stack traces with one or more tokens (e.g. "STACK_TRACE"). Unfortunately it's not so easy to do it (see the discussion in #9).

https://github.com/scikit-learn-contrib/sklearn-pandas

It will ease having multiple pipelines. E.g. if you have two classifiers who are working on two different features, and at the end a voting between them. The sklearn basic FeatureUnion is not a great fit for this use case.

We should just hardcode the data of those bugs.

Depends on #5.

Right now I handpicked the number of most important features to show (the top 20).

We should use an algorithm to select what to show. The simplest two alternatives are:

1. Show all the contributing features that are at least X% of the sum of the contributions.
2. Show the top contributing feature, and all other contributing features that are at least X% of the top one.

The status flags can be particularly useful for detecting e.g. regressions.

Some features I can think of:

• "ever-affected", true if the status has ever been set to 'affected' (while some developers use 'affected' also for features, many use it only for bugs);
• "unaffected-then-affected", true if the status for a given version is unaffected and for a following version is affected.

Instead of .format.

Needed for mozilla/bugbot#223.

To do this, we'll need to collect some labels.
We can automatically create some by using the perf and memory keywords.

There are other types that we could try to classify other than perf and memory:

• Security - Security vulnerability.
• Crash - Program unexpectedly stops running.
• Hang - Program keeps running but without response.
• Incorrect rendering - Components or video cannot be correctly rendered.
• Wrong functionality - Incorrect functionalities besides rendering issues.
• Web incompatibility - Program does not work correctly for a major website or many websites due to incompatible APIs or libraries, or a functionality, which was removed on purpose, but is still used in the wild.
• Add-on or plug-in incompatibility - Program does not work correctly for a major add-on/plug-in or many add-ons/plug-ins due to incompatible APIs or libraries, or a functionality, which was removed on purpose, but is still used in the wild.
• Compile - Compilation errors.
• Feature - Introduce or remove features.
• Improvement - Minor functional or aesthetical improvement.
• Test-only problem - Errors that only break tests.
• Other - Other types that don't belong to the previous categories, e.g., data corruption and license incompatibility.

Where the "experience" of the bug opener is the number of bugs opened so far by the bug opener.

This can be useful for the detection of missing STR (hopefully an experienced bug opener will know that STRs are needed).

I need to update libmozdata to 0.1.45 in auto_nag and your requirement is incompatible (==0.1.44)

These might be useful for the uplift model:

• #3118
• Time delta between uplift request and merge day (we can approximate it with the release date of the next version at the time the uplift was requested) #97

We're currently replacing all DLL names with a DLL_NAME token, but we should differentiate between third-party DLLs and Firefox DLLs (XUL.dll, and so on).

.so and .dylib are DLLs on Linux and Mac. We should replace them with DLL_NAME as we do for .dll files.

Depends on #5.

It's supposed to be particularly effective for gradient boosted trees, which we are using.

They are relics of a previous version of the tool that was based on handwritten rules. We should clean them up and merge them.

https://github.com/scikit-learn-contrib/skope-rules

skope-rules is supposed to return highly-interpretable results, which can be really useful for some of our goals.

See also #8, #39 and #40.

Depends on #5.

Needed for mozilla/bugbot#221.

To do this, we'll need to collect some labels.
We can automatically create positive labels by getting bugs that have the regression keyword and the regression-wanted keyword.
We can't automatically create negative labels because we can't be sure that the regression range is available, when we have the regression keyword but no regression-wanted.

It should be False by default.

Given features from patches (e.g. which files were modified, the components of the modified files, the number of lines modified, the past reviewers of the patch, the past authors of the patch, etc.), we want to be able to identify a good reviewer for a given patch.

This will require a few changes in the project:

1. Collecting even more features on patches;
2. Make it possible to train on patches rather than only bugs (model.py assumes all classifiers operate on bugs, but this one will operate on patches instead);
3. Create the classifier itself!

Right now we are using TfidfVectorizer with its default options (basically word 1-gram). We should try a few different options and see how the accuracy changes:

• word 1-gram
• word 2-gram
• word 3-gram
• char 1-gram
• char 2-gram
• char 3-gram
• word2vec
• doc2vec
• fasttext
• 1d-cnn (with pre-trained word embeddings)
• 1d-cnn (without pre-trained word embeddings)
• bert or similar

A new classifier, similar to the ones already present under bugbug/models/, should be created to predict the assignee of a bug.
This will be similar to the component model, except the label will be the assignee instead of the product/component.

We'll need this for training classifier on some specific problems. E.g. for triaging, we can only use the information about a bug at the time the bug was triaged, we can't use the information that is added after that.

When making a classification, we should also return the features that were most important for the decision.

See also #8.

We could try using the text classifier available in spaCy instead of gradient boosting and see how it behaves.

Needed for mozilla/bugbot#227.

To do this, we'll need to collect some labels.
We can automatically create some positive labels by getting bugs that have the qawanted keyword or that have qe-verify flag.
We can't automatically create negative labels because we can't be sure that QA was not needed when the keyword/flag was not set.

We don't use regression in the training phase to avoid skewing results. In the evaluation phase we should use it though as its presence is a clear indication of a bug/regression, and if it is not present resort to the classifier.

Needed for mozilla/bugbot#222 and mozilla/bugbot#400.

To do this, we'll need to collect some labels.
We can automatically create some positive labels by getting bugs that have the stepswanted keyword.
We can't automatically create negative labels because we can't be sure that STR are available, when we don't have the stepswanted keyword.

For the last decade or so, the MDN Web Docs team relies on people adding "dev-doc-needed" to Bugzilla bugs, so that we can document if Firefox implemented a new Web platform feature or if changes to Web platform features happened in Firefox.

It would be amazing if we wouldn't have to rely so much on humans adding this keyword anymore.
I don't know if this project can help with this, but filing this issue as an idea :)

Prior related bug about this https://bugzilla.mozilla.org/show_bug.cgi?id=1376393

"similar" not in terms of duplicate bug, but in terms of features. E.g. two bugs that are completely unrelated from each other, but that are of the same type and have similarly sized patches.

Similar to #30.

This feature is going to be a boolean saying whether the reporter of the bug is a developer. As a first implementation, we can check if there is any commit where they are authors.

b7369ea introduced the features, but we are still not using them.

The first implementation will simply check if an email contains "@mozilla.com" or "@mozilla.org".

We are not cleaning up the text from title or comments at all, we should:

• replace crash stats references (bp-XXXX, example in https://bugzilla.mozilla.org/show_bug.cgi?id=1376831#c0) with one or more tokens (e.g. "___CRASH_STATS_LINK___")
• replace file references with one or more tokens (e.g. "___FILE_REFERENCE___") - #36.
• replace URLs with one or more tokens (e.g. "___URL___") - #33.
• maybe remove referred text in comments (starting with ">") - #52.
• replace hexadecimal numbers with one or more tokens (e.g. "__HEX_NUMBER__") - #56.
• replace DLL names with one or more tokens (e.g. "__DLL_NAME__"). - #65.

For URLs, we should probably have different tokens according to the type of URL (e.g. if it's a hg.mozilla.org, or searchfox.org or dxr.mozilla.org, then the meaning of the URL might be different).

See also #8 and #39.

Some of our classifiers are operating on the same data, it might make sense to use multitask classification.

When a new DB is available, it should automatically be downloaded.

The first comment might be more important than others for some classifiers (e.g. missing STR), so we should try to consider it separately than the rest of the comments.

For now we're simply randomly under-sampling the majority classes.

E.g. STR == 'Steps to Reproduce' or 'UAF' == 'use after free' == 'use-after-free' and so on.

This is kind of part of #9.