MozillaWiki - User contributions [en]

EngineeringProductivity/Projects/ActiveData

2019-02-27T13:46:00Z

Klahnakoski: /* Users */ add uses

= Overview =

ActiveData is a collection of about 8 billion records (Feb 2016) covering unit tests, Buildbot jobs, performance data, and mercurial. This collection is publicly available, and can be queried directly, similar to any database.

ActiveData is built on top of ElasticSearch, a fast, distributed, redundant document store. ActiveData provides the benefits of familiar and succinct SQL by translating SQL-like queries to ElasticSearch queries,

== Problem ==
In order to improve our testing infrastructure we require data on how that infrastructure is performing. That information can be extracted from the raw logs, but that requires downloading samples, parsing data, insertion into a database (or worse, writing queries in an imperative language, like Python). When we are done an analysis we have effectively built an ETL pipeline that does not scale, and is too specific to be reused elsewhere. The next project does this work all over again.

== Solution==
ActiveData will serve as a reusable ETL pipeline; annotating the test results with as much relevant data as possible. It also provides a query service to explore and aggregate the data, so there is minimal setup required to access this data.

= Redash =
ActiveData has a Redash connector for [https://sql.telemetry.mozilla.org/ stmo] and it accepts SQL. [https://github.com/mozilla/ActiveData/blob/dev/docs/redash.md see main doc for details]

= Charts =

ActiveData is fast enough to support dashboards.

== Build times ==
{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/End-to-End.html End to End Times]
|| Shows overall time from when a build is first requested to the time tests on that build are complete.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Overview.html Build Times]
|| Time series view of build times by platform and build type. Click on a bar to get a scatter plot view.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Detail.html Detailed Build Times]
|| Scatter plot of build times. Use the left navigation panel to choose a combination. Click on a data point to see the Buildbot step times and Mozharness step times.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Buildbot-Simulator.html Buildbot Simulator] incomplete
|| An incomplete Buildbot scheduling simulator. It can be used to see past wait times, queue size, and inter-job delays.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/index.html Test Runtimes]
|| Choose test suite and machine pool to get an average run time for each of the buildbot steps, and Mozharness steps.
|}

==Unit Test Visualization==
With all unit test results in ActiveData, we can get accurate estimates of "failure rate"; and be able to focus on the most-failing tests.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/index.html Top Intermittent Failures]
|| List of top 30 most-failing unit tests, and list of top 30 most-recent failing tests. Click on the link to get a scatterplot.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/test.html Find Test Results]
|| Use the search bar to find a test. A list of matching tests, and platform combinations will show the unit test failures and durations.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/NeglectedOranges/index.html Neglected Oranges]
|| Cross reference OrangeFactor and Bugzilla to give a list of frequent intermittents that have no bug activity.
|}

= Design =
ActiveData attempts to provide the benefits of an available database to the public; except larger and faster.

== Goals ==
An active data instance distinguishes itself from a static resource, or database, or big data solution, by delivering a particular set of features:
* '''A service, open to third party clients''' - By providing the service, clients don't need to setup their own datastore
* '''Fast filtering''' - Sub-second filtering over the contents of the whole datastore, independent of size, saves the application developer from declaring and managing indexes that do the same: There is sufficient information in the queries to determine which indexes should be built to deliver a quick response.
* '''Fast aggregates''' - Sub-second calculation of statistics over the whole datastore saves the application developer from building and managing caches of those aggregates.
* '''API is a query language (SQL?, MDX?)''' - Building upon the formalisms, and familiarity, of existing query languages, we reduce the learning curve, and also provide Active Data implementations with more insight into the intent of the client application; and optimize for its use cases.
* '''Uniform, Cartesian space of values''' - Mozilla has a mandate of data driven decision making. Data analysis tools, like Spreadsheets, R, Scipy, Numpy, and Pandas are used to perform data analysis, and they all require uniform data in multi-dimensional arrays, commonly known as "pivot tables" or "data frames". ActiveData's objective is to provide query results in these formats
* '''Metadata on dimensions and measures''' - ActiveData also provides context to the data it holds. It serves the purpose to allow exploration and discovery by third parties; by describing unit-of-measure, how dimensions relate to others, and provide human descriptions of the columns stored. This metadata is also invaluable in automating the orientation and formatting of dashboard charts: Knowing the domain of an axis allows code to decide the best (default) chart form, and provides logically reasonable aggregate options.
* '''Has a security model''' - Simpler applications can avoid the complications of a security model if it is baked into the ActiveData solution. If ActiveData is to become mainstream it is important that it can manage sensitive data and PII.

== Limitations ==

The unittest data is limited to those test suites that generate structured logs. Currently (Feb, 2016) the following do NOT have structured logs, and are NOT in ActiveData:

* cppunittest
* and any of the js based gaia suites (e.g Gij)

Specifically, you can see if a structured log is being generated: In Treeherder, click a job. Under the "Job details" pane at the bottom, look for a line similar to:

<blockquote> ''artifact uploaded: <suite>_raw.log''
</blockquote>

If you see that, it is using structured logging.

ActiveData makes specific tradeoffs to achieve its goals. It has the following limitations:
* large memory requirements
* low add/update/remove speeds
* strict data model (snowflake schema, hierarchical relations only)
* non-relational
* ETL work required to de-normalize data
* ETL work required to provide dimension metadata

== Non Goals ==
ActiveData is not meant to replace an application database. Applications often track significantly more data related to good interface design, process sequences, complex relations, and object life cycles.
ActiveData's simple model makes it difficult to track object life cycles and impossible to model many-to-many relations.
Data is not live, and definitely does not track "pending jobs" like TreeHerder or TaskCluster do. Test results may take a day, or more, to be indexed.

= Dependencies / Who will use this =
== Dependencies ==

ActiveData's ETL pipeline ingests data from a variety of sources:

* Structured Logs from Unittests
* Task Cluster tasks
** including mozharness timings
* PerfHerder at a per-replicate level
* Treeherder
* hg.mozilla.org branches and revisions
* code coverage (all tests, all files, all lines)
* various logs from ETL pipeline
* all firefox files and related components
* firefox testing results
* old buildbot jobs

== Users ==

ActiveData's primary goal is to support dashboards that give Mozilla useful perspectives into the large amount of data:

* [https://github.com/mozilla/active-data-recipes/tree/master/adr/recipes ActiveData Recipes has a variety of use cases]
* Individual unit test results
* Task cluster test timing
* Firefox compile times
* Recently new, removed, and disabled tests
* Buildbot wait times
* CodeCoverage aggregates and per-file detail

= Let's Use It! =

The service listens at http://activedata.allizom.org/query and accepts queries in [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md JSON Query Expression format].

curl -XPOST -d "{\"from\":\"unittest\"}" http://activedata.allizom.org/query

== The Query Tool ==
The ActiveData service is intended for use by automated clients, not humans. The [http://activedata.allizom.org/tools/query.html Query Tool] is a minimal web page for humans to do some exploration, and to test phrasing queries.
* [http://activedata.allizom.org/tools/query.html ActiveData QueryTool]

== Documentation ==
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md tutorial]
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Unittest%20Schema.md Unit test results schema]
* [https://github.com/mozilla/ActiveData/blob/dev/docs/schemas_190227.md Listing of current schemas]

= Code =
Development is still in the early stages, setting up your own service
* Github: https://github.com/klahnakoski/ActiveData

= Contact =

* Kyle Lahnakoski
** IRC: ekyle@irc.mozilla.org
** Email: klahnakoski@mozilla.org
** Bugzilla: :ekyle

= More Context=
Mostly rambling, optional reading.

== Inspiration==
This project is inspired by the data warehouse and data mart technology that is common inside large corporations. These warehouses are useful because they are "active" services: This means the data is not only available, but it can be explored interactively by large audience using a query language.

== General Problem ==
A significant portion of any application is the backend database/datastore, which include:
* Managing resources and machines to support the datastore
* Data migrations on schemas during application lifetime
* Manually defining database indexes for responsive data retrieval
* Coding caching logic to reduce application latency

The manual effort put toward these features becomes significant as the amount of data grows in size and complexity. More importantly, this effort is being spent over and over on a multitude of applications, each a trivial variation of the next.

==General Solution==

Abstractly, we desire to reduce this redundant workload by adding a layer of abstraction called ActiveData: Clients using ActiveData benefit from the features it provides and avoid the datastore management complexities. While the ActiveData implementers can focus on these common issues while being given a simpler data model, and simpler query language, upon which to calculate optimizations.

Columnar datastores, have solved many (but not all) problems with changing schema. Query-directed indexing has been around for decades in Oracle's query optimization algorithms, and are available for free in ElasticSearch. We now have the technology to build an ActiveData solution.

By defining an ActiveData standard, we can innovate on both sides of the ActiveData abstraction layer independently

== Client Architecture ==

Applications that leverage an active data warehouse can forgo significant server side development, if not all, and put the logic on the client side.

EngineeringProductivity/Projects/ActiveData

2019-02-27T13:31:52Z

Klahnakoski: /* Dependencies */ typo

= Overview =

ActiveData is a collection of about 8 billion records (Feb 2016) covering unit tests, Buildbot jobs, performance data, and mercurial. This collection is publicly available, and can be queried directly, similar to any database.

ActiveData is built on top of ElasticSearch, a fast, distributed, redundant document store. ActiveData provides the benefits of familiar and succinct SQL by translating SQL-like queries to ElasticSearch queries,

== Problem ==
In order to improve our testing infrastructure we require data on how that infrastructure is performing. That information can be extracted from the raw logs, but that requires downloading samples, parsing data, insertion into a database (or worse, writing queries in an imperative language, like Python). When we are done an analysis we have effectively built an ETL pipeline that does not scale, and is too specific to be reused elsewhere. The next project does this work all over again.

== Solution==
ActiveData will serve as a reusable ETL pipeline; annotating the test results with as much relevant data as possible. It also provides a query service to explore and aggregate the data, so there is minimal setup required to access this data.

= Redash =
ActiveData has a Redash connector for [https://sql.telemetry.mozilla.org/ stmo] and it accepts SQL. [https://github.com/mozilla/ActiveData/blob/dev/docs/redash.md see main doc for details]

= Charts =

ActiveData is fast enough to support dashboards.

== Build times ==
{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/End-to-End.html End to End Times]
|| Shows overall time from when a build is first requested to the time tests on that build are complete.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Overview.html Build Times]
|| Time series view of build times by platform and build type. Click on a bar to get a scatter plot view.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Detail.html Detailed Build Times]
|| Scatter plot of build times. Use the left navigation panel to choose a combination. Click on a data point to see the Buildbot step times and Mozharness step times.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Buildbot-Simulator.html Buildbot Simulator] incomplete
|| An incomplete Buildbot scheduling simulator. It can be used to see past wait times, queue size, and inter-job delays.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/index.html Test Runtimes]
|| Choose test suite and machine pool to get an average run time for each of the buildbot steps, and Mozharness steps.
|}

==Unit Test Visualization==
With all unit test results in ActiveData, we can get accurate estimates of "failure rate"; and be able to focus on the most-failing tests.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/index.html Top Intermittent Failures]
|| List of top 30 most-failing unit tests, and list of top 30 most-recent failing tests. Click on the link to get a scatterplot.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/test.html Find Test Results]
|| Use the search bar to find a test. A list of matching tests, and platform combinations will show the unit test failures and durations.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/NeglectedOranges/index.html Neglected Oranges]
|| Cross reference OrangeFactor and Bugzilla to give a list of frequent intermittents that have no bug activity.
|}

= Design =
ActiveData attempts to provide the benefits of an available database to the public; except larger and faster.

== Goals ==
An active data instance distinguishes itself from a static resource, or database, or big data solution, by delivering a particular set of features:
* '''A service, open to third party clients''' - By providing the service, clients don't need to setup their own datastore
* '''Fast filtering''' - Sub-second filtering over the contents of the whole datastore, independent of size, saves the application developer from declaring and managing indexes that do the same: There is sufficient information in the queries to determine which indexes should be built to deliver a quick response.
* '''Fast aggregates''' - Sub-second calculation of statistics over the whole datastore saves the application developer from building and managing caches of those aggregates.
* '''API is a query language (SQL?, MDX?)''' - Building upon the formalisms, and familiarity, of existing query languages, we reduce the learning curve, and also provide Active Data implementations with more insight into the intent of the client application; and optimize for its use cases.
* '''Uniform, Cartesian space of values''' - Mozilla has a mandate of data driven decision making. Data analysis tools, like Spreadsheets, R, Scipy, Numpy, and Pandas are used to perform data analysis, and they all require uniform data in multi-dimensional arrays, commonly known as "pivot tables" or "data frames". ActiveData's objective is to provide query results in these formats
* '''Metadata on dimensions and measures''' - ActiveData also provides context to the data it holds. It serves the purpose to allow exploration and discovery by third parties; by describing unit-of-measure, how dimensions relate to others, and provide human descriptions of the columns stored. This metadata is also invaluable in automating the orientation and formatting of dashboard charts: Knowing the domain of an axis allows code to decide the best (default) chart form, and provides logically reasonable aggregate options.
* '''Has a security model''' - Simpler applications can avoid the complications of a security model if it is baked into the ActiveData solution. If ActiveData is to become mainstream it is important that it can manage sensitive data and PII.

== Limitations ==

The unittest data is limited to those test suites that generate structured logs. Currently (Feb, 2016) the following do NOT have structured logs, and are NOT in ActiveData:

* cppunittest
* and any of the js based gaia suites (e.g Gij)

Specifically, you can see if a structured log is being generated: In Treeherder, click a job. Under the "Job details" pane at the bottom, look for a line similar to:

<blockquote> ''artifact uploaded: <suite>_raw.log''
</blockquote>

If you see that, it is using structured logging.

ActiveData makes specific tradeoffs to achieve its goals. It has the following limitations:
* large memory requirements
* low add/update/remove speeds
* strict data model (snowflake schema, hierarchical relations only)
* non-relational
* ETL work required to de-normalize data
* ETL work required to provide dimension metadata

== Non Goals ==
ActiveData is not meant to replace an application database. Applications often track significantly more data related to good interface design, process sequences, complex relations, and object life cycles.
ActiveData's simple model makes it difficult to track object life cycles and impossible to model many-to-many relations.
Data is not live, and definitely does not track "pending jobs" like TreeHerder or TaskCluster do. Test results may take a day, or more, to be indexed.

= Dependencies / Who will use this =
== Dependencies ==

ActiveData's ETL pipeline ingests data from a variety of sources:

* Structured Logs from Unittests
* Task Cluster tasks
** including mozharness timings
* PerfHerder at a per-replicate level
* Treeherder
* hg.mozilla.org branches and revisions
* code coverage (all tests, all files, all lines)
* various logs from ETL pipeline
* all firefox files and related components
* firefox testing results
* old buildbot jobs

== Users ==

ActiveData's primary goal is to support dashboards that give Mozilla useful perspectives into the large amount of data:

* Individual unit test results
* Buildbot test times
* Firefox compile times
* Recently new, removed, and disabled tests
* Buildbot wait times

= Let's Use It! =

The service listens at http://activedata.allizom.org/query and accepts queries in [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md JSON Query Expression format].

curl -XPOST -d "{\"from\":\"unittest\"}" http://activedata.allizom.org/query

== The Query Tool ==
The ActiveData service is intended for use by automated clients, not humans. The [http://activedata.allizom.org/tools/query.html Query Tool] is a minimal web page for humans to do some exploration, and to test phrasing queries.
* [http://activedata.allizom.org/tools/query.html ActiveData QueryTool]

== Documentation ==
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md tutorial]
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Unittest%20Schema.md Unit test results schema]
* [https://github.com/mozilla/ActiveData/blob/dev/docs/schemas_190227.md Listing of current schemas]

= Code =
Development is still in the early stages, setting up your own service
* Github: https://github.com/klahnakoski/ActiveData

= Contact =

* Kyle Lahnakoski
** IRC: ekyle@irc.mozilla.org
** Email: klahnakoski@mozilla.org
** Bugzilla: :ekyle

= More Context=
Mostly rambling, optional reading.

== Inspiration==
This project is inspired by the data warehouse and data mart technology that is common inside large corporations. These warehouses are useful because they are "active" services: This means the data is not only available, but it can be explored interactively by large audience using a query language.

== General Problem ==
A significant portion of any application is the backend database/datastore, which include:
* Managing resources and machines to support the datastore
* Data migrations on schemas during application lifetime
* Manually defining database indexes for responsive data retrieval
* Coding caching logic to reduce application latency

The manual effort put toward these features becomes significant as the amount of data grows in size and complexity. More importantly, this effort is being spent over and over on a multitude of applications, each a trivial variation of the next.

==General Solution==

Abstractly, we desire to reduce this redundant workload by adding a layer of abstraction called ActiveData: Clients using ActiveData benefit from the features it provides and avoid the datastore management complexities. While the ActiveData implementers can focus on these common issues while being given a simpler data model, and simpler query language, upon which to calculate optimizations.

Columnar datastores, have solved many (but not all) problems with changing schema. Query-directed indexing has been around for decades in Oracle's query optimization algorithms, and are available for free in ElasticSearch. We now have the technology to build an ActiveData solution.

By defining an ActiveData standard, we can innovate on both sides of the ActiveData abstraction layer independently

== Client Architecture ==

Applications that leverage an active data warehouse can forgo significant server side development, if not all, and put the logic on the client side.

EngineeringProductivity/Projects/ActiveData

2019-02-27T13:31:31Z

Klahnakoski: /* Dependencies */ fix indent

= Overview =

ActiveData is a collection of about 8 billion records (Feb 2016) covering unit tests, Buildbot jobs, performance data, and mercurial. This collection is publicly available, and can be queried directly, similar to any database.

ActiveData is built on top of ElasticSearch, a fast, distributed, redundant document store. ActiveData provides the benefits of familiar and succinct SQL by translating SQL-like queries to ElasticSearch queries,

== Problem ==
In order to improve our testing infrastructure we require data on how that infrastructure is performing. That information can be extracted from the raw logs, but that requires downloading samples, parsing data, insertion into a database (or worse, writing queries in an imperative language, like Python). When we are done an analysis we have effectively built an ETL pipeline that does not scale, and is too specific to be reused elsewhere. The next project does this work all over again.

== Solution==
ActiveData will serve as a reusable ETL pipeline; annotating the test results with as much relevant data as possible. It also provides a query service to explore and aggregate the data, so there is minimal setup required to access this data.

= Redash =
ActiveData has a Redash connector for [https://sql.telemetry.mozilla.org/ stmo] and it accepts SQL. [https://github.com/mozilla/ActiveData/blob/dev/docs/redash.md see main doc for details]

= Charts =

ActiveData is fast enough to support dashboards.

== Build times ==
{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/End-to-End.html End to End Times]
|| Shows overall time from when a build is first requested to the time tests on that build are complete.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Overview.html Build Times]
|| Time series view of build times by platform and build type. Click on a bar to get a scatter plot view.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Detail.html Detailed Build Times]
|| Scatter plot of build times. Use the left navigation panel to choose a combination. Click on a data point to see the Buildbot step times and Mozharness step times.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Buildbot-Simulator.html Buildbot Simulator] incomplete
|| An incomplete Buildbot scheduling simulator. It can be used to see past wait times, queue size, and inter-job delays.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/index.html Test Runtimes]
|| Choose test suite and machine pool to get an average run time for each of the buildbot steps, and Mozharness steps.
|}

==Unit Test Visualization==
With all unit test results in ActiveData, we can get accurate estimates of "failure rate"; and be able to focus on the most-failing tests.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/index.html Top Intermittent Failures]
|| List of top 30 most-failing unit tests, and list of top 30 most-recent failing tests. Click on the link to get a scatterplot.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/test.html Find Test Results]
|| Use the search bar to find a test. A list of matching tests, and platform combinations will show the unit test failures and durations.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/NeglectedOranges/index.html Neglected Oranges]
|| Cross reference OrangeFactor and Bugzilla to give a list of frequent intermittents that have no bug activity.
|}

= Design =
ActiveData attempts to provide the benefits of an available database to the public; except larger and faster.

== Goals ==
An active data instance distinguishes itself from a static resource, or database, or big data solution, by delivering a particular set of features:
* '''A service, open to third party clients''' - By providing the service, clients don't need to setup their own datastore
* '''Fast filtering''' - Sub-second filtering over the contents of the whole datastore, independent of size, saves the application developer from declaring and managing indexes that do the same: There is sufficient information in the queries to determine which indexes should be built to deliver a quick response.
* '''Fast aggregates''' - Sub-second calculation of statistics over the whole datastore saves the application developer from building and managing caches of those aggregates.
* '''API is a query language (SQL?, MDX?)''' - Building upon the formalisms, and familiarity, of existing query languages, we reduce the learning curve, and also provide Active Data implementations with more insight into the intent of the client application; and optimize for its use cases.
* '''Uniform, Cartesian space of values''' - Mozilla has a mandate of data driven decision making. Data analysis tools, like Spreadsheets, R, Scipy, Numpy, and Pandas are used to perform data analysis, and they all require uniform data in multi-dimensional arrays, commonly known as "pivot tables" or "data frames". ActiveData's objective is to provide query results in these formats
* '''Metadata on dimensions and measures''' - ActiveData also provides context to the data it holds. It serves the purpose to allow exploration and discovery by third parties; by describing unit-of-measure, how dimensions relate to others, and provide human descriptions of the columns stored. This metadata is also invaluable in automating the orientation and formatting of dashboard charts: Knowing the domain of an axis allows code to decide the best (default) chart form, and provides logically reasonable aggregate options.
* '''Has a security model''' - Simpler applications can avoid the complications of a security model if it is baked into the ActiveData solution. If ActiveData is to become mainstream it is important that it can manage sensitive data and PII.

== Limitations ==

The unittest data is limited to those test suites that generate structured logs. Currently (Feb, 2016) the following do NOT have structured logs, and are NOT in ActiveData:

* cppunittest
* and any of the js based gaia suites (e.g Gij)

Specifically, you can see if a structured log is being generated: In Treeherder, click a job. Under the "Job details" pane at the bottom, look for a line similar to:

<blockquote> ''artifact uploaded: <suite>_raw.log''
</blockquote>

If you see that, it is using structured logging.

ActiveData makes specific tradeoffs to achieve its goals. It has the following limitations:
* large memory requirements
* low add/update/remove speeds
* strict data model (snowflake schema, hierarchical relations only)
* non-relational
* ETL work required to de-normalize data
* ETL work required to provide dimension metadata

== Non Goals ==
ActiveData is not meant to replace an application database. Applications often track significantly more data related to good interface design, process sequences, complex relations, and object life cycles.
ActiveData's simple model makes it difficult to track object life cycles and impossible to model many-to-many relations.
Data is not live, and definitely does not track "pending jobs" like TreeHerder or TaskCluster do. Test results may take a day, or more, to be indexed.

= Dependencies / Who will use this =
== Dependencies ==

ActiveData's ETL pipeline ingests data from a variety of sources:

* Structured Logs from Unittests
* Task Cluster tasks
** uncluding mozharness timings
* PerfHerder at a per-replicate level
* Treeherder
* hg.mozilla.org branches and revisions
* code coverage (all tests, all files, all lines)
* various logs from ETL pipeline
* all firefox files and related components
* firefox testing results
* old buildbot jobs

== Users ==

ActiveData's primary goal is to support dashboards that give Mozilla useful perspectives into the large amount of data:

* Individual unit test results
* Buildbot test times
* Firefox compile times
* Recently new, removed, and disabled tests
* Buildbot wait times

= Let's Use It! =

The service listens at http://activedata.allizom.org/query and accepts queries in [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md JSON Query Expression format].

curl -XPOST -d "{\"from\":\"unittest\"}" http://activedata.allizom.org/query

== The Query Tool ==
The ActiveData service is intended for use by automated clients, not humans. The [http://activedata.allizom.org/tools/query.html Query Tool] is a minimal web page for humans to do some exploration, and to test phrasing queries.
* [http://activedata.allizom.org/tools/query.html ActiveData QueryTool]

== Documentation ==
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md tutorial]
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Unittest%20Schema.md Unit test results schema]
* [https://github.com/mozilla/ActiveData/blob/dev/docs/schemas_190227.md Listing of current schemas]

= Code =
Development is still in the early stages, setting up your own service
* Github: https://github.com/klahnakoski/ActiveData

= Contact =

* Kyle Lahnakoski
** IRC: ekyle@irc.mozilla.org
** Email: klahnakoski@mozilla.org
** Bugzilla: :ekyle

= More Context=
Mostly rambling, optional reading.

== Inspiration==
This project is inspired by the data warehouse and data mart technology that is common inside large corporations. These warehouses are useful because they are "active" services: This means the data is not only available, but it can be explored interactively by large audience using a query language.

== General Problem ==
A significant portion of any application is the backend database/datastore, which include:
* Managing resources and machines to support the datastore
* Data migrations on schemas during application lifetime
* Manually defining database indexes for responsive data retrieval
* Coding caching logic to reduce application latency

The manual effort put toward these features becomes significant as the amount of data grows in size and complexity. More importantly, this effort is being spent over and over on a multitude of applications, each a trivial variation of the next.

==General Solution==

Abstractly, we desire to reduce this redundant workload by adding a layer of abstraction called ActiveData: Clients using ActiveData benefit from the features it provides and avoid the datastore management complexities. While the ActiveData implementers can focus on these common issues while being given a simpler data model, and simpler query language, upon which to calculate optimizations.

Columnar datastores, have solved many (but not all) problems with changing schema. Query-directed indexing has been around for decades in Oracle's query optimization algorithms, and are available for free in ElasticSearch. We now have the technology to build an ActiveData solution.

By defining an ActiveData standard, we can innovate on both sides of the ActiveData abstraction layer independently

== Client Architecture ==

Applications that leverage an active data warehouse can forgo significant server side development, if not all, and put the logic on the client side.

EngineeringProductivity/Projects/ActiveData

2019-02-27T13:30:58Z

Klahnakoski: /* Dependencies */ add to list

= Overview =

ActiveData is a collection of about 8 billion records (Feb 2016) covering unit tests, Buildbot jobs, performance data, and mercurial. This collection is publicly available, and can be queried directly, similar to any database.

ActiveData is built on top of ElasticSearch, a fast, distributed, redundant document store. ActiveData provides the benefits of familiar and succinct SQL by translating SQL-like queries to ElasticSearch queries,

== Problem ==
In order to improve our testing infrastructure we require data on how that infrastructure is performing. That information can be extracted from the raw logs, but that requires downloading samples, parsing data, insertion into a database (or worse, writing queries in an imperative language, like Python). When we are done an analysis we have effectively built an ETL pipeline that does not scale, and is too specific to be reused elsewhere. The next project does this work all over again.

== Solution==
ActiveData will serve as a reusable ETL pipeline; annotating the test results with as much relevant data as possible. It also provides a query service to explore and aggregate the data, so there is minimal setup required to access this data.

= Redash =
ActiveData has a Redash connector for [https://sql.telemetry.mozilla.org/ stmo] and it accepts SQL. [https://github.com/mozilla/ActiveData/blob/dev/docs/redash.md see main doc for details]

= Charts =

ActiveData is fast enough to support dashboards.

== Build times ==
{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/End-to-End.html End to End Times]
|| Shows overall time from when a build is first requested to the time tests on that build are complete.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Overview.html Build Times]
|| Time series view of build times by platform and build type. Click on a bar to get a scatter plot view.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Detail.html Detailed Build Times]
|| Scatter plot of build times. Use the left navigation panel to choose a combination. Click on a data point to see the Buildbot step times and Mozharness step times.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Buildbot-Simulator.html Buildbot Simulator] incomplete
|| An incomplete Buildbot scheduling simulator. It can be used to see past wait times, queue size, and inter-job delays.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/index.html Test Runtimes]
|| Choose test suite and machine pool to get an average run time for each of the buildbot steps, and Mozharness steps.
|}

==Unit Test Visualization==
With all unit test results in ActiveData, we can get accurate estimates of "failure rate"; and be able to focus on the most-failing tests.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/index.html Top Intermittent Failures]
|| List of top 30 most-failing unit tests, and list of top 30 most-recent failing tests. Click on the link to get a scatterplot.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/test.html Find Test Results]
|| Use the search bar to find a test. A list of matching tests, and platform combinations will show the unit test failures and durations.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/NeglectedOranges/index.html Neglected Oranges]
|| Cross reference OrangeFactor and Bugzilla to give a list of frequent intermittents that have no bug activity.
|}

= Design =
ActiveData attempts to provide the benefits of an available database to the public; except larger and faster.

== Goals ==
An active data instance distinguishes itself from a static resource, or database, or big data solution, by delivering a particular set of features:
* '''A service, open to third party clients''' - By providing the service, clients don't need to setup their own datastore
* '''Fast filtering''' - Sub-second filtering over the contents of the whole datastore, independent of size, saves the application developer from declaring and managing indexes that do the same: There is sufficient information in the queries to determine which indexes should be built to deliver a quick response.
* '''Fast aggregates''' - Sub-second calculation of statistics over the whole datastore saves the application developer from building and managing caches of those aggregates.
* '''API is a query language (SQL?, MDX?)''' - Building upon the formalisms, and familiarity, of existing query languages, we reduce the learning curve, and also provide Active Data implementations with more insight into the intent of the client application; and optimize for its use cases.
* '''Uniform, Cartesian space of values''' - Mozilla has a mandate of data driven decision making. Data analysis tools, like Spreadsheets, R, Scipy, Numpy, and Pandas are used to perform data analysis, and they all require uniform data in multi-dimensional arrays, commonly known as "pivot tables" or "data frames". ActiveData's objective is to provide query results in these formats
* '''Metadata on dimensions and measures''' - ActiveData also provides context to the data it holds. It serves the purpose to allow exploration and discovery by third parties; by describing unit-of-measure, how dimensions relate to others, and provide human descriptions of the columns stored. This metadata is also invaluable in automating the orientation and formatting of dashboard charts: Knowing the domain of an axis allows code to decide the best (default) chart form, and provides logically reasonable aggregate options.
* '''Has a security model''' - Simpler applications can avoid the complications of a security model if it is baked into the ActiveData solution. If ActiveData is to become mainstream it is important that it can manage sensitive data and PII.

== Limitations ==

The unittest data is limited to those test suites that generate structured logs. Currently (Feb, 2016) the following do NOT have structured logs, and are NOT in ActiveData:

* cppunittest
* and any of the js based gaia suites (e.g Gij)

Specifically, you can see if a structured log is being generated: In Treeherder, click a job. Under the "Job details" pane at the bottom, look for a line similar to:

<blockquote> ''artifact uploaded: <suite>_raw.log''
</blockquote>

If you see that, it is using structured logging.

ActiveData makes specific tradeoffs to achieve its goals. It has the following limitations:
* large memory requirements
* low add/update/remove speeds
* strict data model (snowflake schema, hierarchical relations only)
* non-relational
* ETL work required to de-normalize data
* ETL work required to provide dimension metadata

== Non Goals ==
ActiveData is not meant to replace an application database. Applications often track significantly more data related to good interface design, process sequences, complex relations, and object life cycles.
ActiveData's simple model makes it difficult to track object life cycles and impossible to model many-to-many relations.
Data is not live, and definitely does not track "pending jobs" like TreeHerder or TaskCluster do. Test results may take a day, or more, to be indexed.

= Dependencies / Who will use this =
== Dependencies ==

ActiveData's ETL pipeline ingests data from a variety of sources:

* Structured Logs from Unittests
* Task Cluster tasks
* uncluding mozharness timings
* PerfHerder at a per-replicate level
* Treeherder
* hg.mozilla.org branches and revisions
* code coverage (all tests, all files, all lines)
* various logs from ETL pipeline
* all firefox files and related components
* firefox testing results
* old buildbot jobs

== Users ==

ActiveData's primary goal is to support dashboards that give Mozilla useful perspectives into the large amount of data:

* Individual unit test results
* Buildbot test times
* Firefox compile times
* Recently new, removed, and disabled tests
* Buildbot wait times

= Let's Use It! =

The service listens at http://activedata.allizom.org/query and accepts queries in [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md JSON Query Expression format].

curl -XPOST -d "{\"from\":\"unittest\"}" http://activedata.allizom.org/query

== The Query Tool ==
The ActiveData service is intended for use by automated clients, not humans. The [http://activedata.allizom.org/tools/query.html Query Tool] is a minimal web page for humans to do some exploration, and to test phrasing queries.
* [http://activedata.allizom.org/tools/query.html ActiveData QueryTool]

== Documentation ==
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md tutorial]
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Unittest%20Schema.md Unit test results schema]
* [https://github.com/mozilla/ActiveData/blob/dev/docs/schemas_190227.md Listing of current schemas]

= Code =
Development is still in the early stages, setting up your own service
* Github: https://github.com/klahnakoski/ActiveData

= Contact =

* Kyle Lahnakoski
** IRC: ekyle@irc.mozilla.org
** Email: klahnakoski@mozilla.org
** Bugzilla: :ekyle

= More Context=
Mostly rambling, optional reading.

== Inspiration==
This project is inspired by the data warehouse and data mart technology that is common inside large corporations. These warehouses are useful because they are "active" services: This means the data is not only available, but it can be explored interactively by large audience using a query language.

== General Problem ==
A significant portion of any application is the backend database/datastore, which include:
* Managing resources and machines to support the datastore
* Data migrations on schemas during application lifetime
* Manually defining database indexes for responsive data retrieval
* Coding caching logic to reduce application latency

The manual effort put toward these features becomes significant as the amount of data grows in size and complexity. More importantly, this effort is being spent over and over on a multitude of applications, each a trivial variation of the next.

==General Solution==

Abstractly, we desire to reduce this redundant workload by adding a layer of abstraction called ActiveData: Clients using ActiveData benefit from the features it provides and avoid the datastore management complexities. While the ActiveData implementers can focus on these common issues while being given a simpler data model, and simpler query language, upon which to calculate optimizations.

Columnar datastores, have solved many (but not all) problems with changing schema. Query-directed indexing has been around for decades in Oracle's query optimization algorithms, and are available for free in ElasticSearch. We now have the technology to build an ActiveData solution.

By defining an ActiveData standard, we can innovate on both sides of the ActiveData abstraction layer independently

== Client Architecture ==

Applications that leverage an active data warehouse can forgo significant server side development, if not all, and put the logic on the client side.

EngineeringProductivity/Projects/ActiveData

2019-02-27T12:56:24Z

Klahnakoski: /* Documentation */ add schema link

= Overview =

ActiveData is a collection of about 8 billion records (Feb 2016) covering unit tests, Buildbot jobs, performance data, and mercurial. This collection is publicly available, and can be queried directly, similar to any database.

ActiveData is built on top of ElasticSearch, a fast, distributed, redundant document store. ActiveData provides the benefits of familiar and succinct SQL by translating SQL-like queries to ElasticSearch queries,

== Problem ==
In order to improve our testing infrastructure we require data on how that infrastructure is performing. That information can be extracted from the raw logs, but that requires downloading samples, parsing data, insertion into a database (or worse, writing queries in an imperative language, like Python). When we are done an analysis we have effectively built an ETL pipeline that does not scale, and is too specific to be reused elsewhere. The next project does this work all over again.

== Solution==
ActiveData will serve as a reusable ETL pipeline; annotating the test results with as much relevant data as possible. It also provides a query service to explore and aggregate the data, so there is minimal setup required to access this data.

= Redash =
ActiveData has a Redash connector for [https://sql.telemetry.mozilla.org/ stmo] and it accepts SQL. [https://github.com/mozilla/ActiveData/blob/dev/docs/redash.md see main doc for details]

= Charts =

ActiveData is fast enough to support dashboards.

== Build times ==
{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/End-to-End.html End to End Times]
|| Shows overall time from when a build is first requested to the time tests on that build are complete.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Overview.html Build Times]
|| Time series view of build times by platform and build type. Click on a bar to get a scatter plot view.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Detail.html Detailed Build Times]
|| Scatter plot of build times. Use the left navigation panel to choose a combination. Click on a data point to see the Buildbot step times and Mozharness step times.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Buildbot-Simulator.html Buildbot Simulator] incomplete
|| An incomplete Buildbot scheduling simulator. It can be used to see past wait times, queue size, and inter-job delays.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/index.html Test Runtimes]
|| Choose test suite and machine pool to get an average run time for each of the buildbot steps, and Mozharness steps.
|}

==Unit Test Visualization==
With all unit test results in ActiveData, we can get accurate estimates of "failure rate"; and be able to focus on the most-failing tests.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/index.html Top Intermittent Failures]
|| List of top 30 most-failing unit tests, and list of top 30 most-recent failing tests. Click on the link to get a scatterplot.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/test.html Find Test Results]
|| Use the search bar to find a test. A list of matching tests, and platform combinations will show the unit test failures and durations.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/NeglectedOranges/index.html Neglected Oranges]
|| Cross reference OrangeFactor and Bugzilla to give a list of frequent intermittents that have no bug activity.
|}

= Design =
ActiveData attempts to provide the benefits of an available database to the public; except larger and faster.

== Goals ==
An active data instance distinguishes itself from a static resource, or database, or big data solution, by delivering a particular set of features:
* '''A service, open to third party clients''' - By providing the service, clients don't need to setup their own datastore
* '''Fast filtering''' - Sub-second filtering over the contents of the whole datastore, independent of size, saves the application developer from declaring and managing indexes that do the same: There is sufficient information in the queries to determine which indexes should be built to deliver a quick response.
* '''Fast aggregates''' - Sub-second calculation of statistics over the whole datastore saves the application developer from building and managing caches of those aggregates.
* '''API is a query language (SQL?, MDX?)''' - Building upon the formalisms, and familiarity, of existing query languages, we reduce the learning curve, and also provide Active Data implementations with more insight into the intent of the client application; and optimize for its use cases.
* '''Uniform, Cartesian space of values''' - Mozilla has a mandate of data driven decision making. Data analysis tools, like Spreadsheets, R, Scipy, Numpy, and Pandas are used to perform data analysis, and they all require uniform data in multi-dimensional arrays, commonly known as "pivot tables" or "data frames". ActiveData's objective is to provide query results in these formats
* '''Metadata on dimensions and measures''' - ActiveData also provides context to the data it holds. It serves the purpose to allow exploration and discovery by third parties; by describing unit-of-measure, how dimensions relate to others, and provide human descriptions of the columns stored. This metadata is also invaluable in automating the orientation and formatting of dashboard charts: Knowing the domain of an axis allows code to decide the best (default) chart form, and provides logically reasonable aggregate options.
* '''Has a security model''' - Simpler applications can avoid the complications of a security model if it is baked into the ActiveData solution. If ActiveData is to become mainstream it is important that it can manage sensitive data and PII.

== Limitations ==

The unittest data is limited to those test suites that generate structured logs. Currently (Feb, 2016) the following do NOT have structured logs, and are NOT in ActiveData:

* cppunittest
* and any of the js based gaia suites (e.g Gij)

Specifically, you can see if a structured log is being generated: In Treeherder, click a job. Under the "Job details" pane at the bottom, look for a line similar to:

<blockquote> ''artifact uploaded: <suite>_raw.log''
</blockquote>

If you see that, it is using structured logging.

ActiveData makes specific tradeoffs to achieve its goals. It has the following limitations:
* large memory requirements
* low add/update/remove speeds
* strict data model (snowflake schema, hierarchical relations only)
* non-relational
* ETL work required to de-normalize data
* ETL work required to provide dimension metadata

== Non Goals ==
ActiveData is not meant to replace an application database. Applications often track significantly more data related to good interface design, process sequences, complex relations, and object life cycles.
ActiveData's simple model makes it difficult to track object life cycles and impossible to model many-to-many relations.
Data is not live, and definitely does not track "pending jobs" like TreeHerder or TaskCluster do. Test results may take a day, or more, to be indexed.

= Dependencies / Who will use this =
== Dependencies ==

ActiveData's ETL pipeline ingests data from a variety of sources:

* Buildbot
* Mozharness
* Structured Logs
* Task Cluster (end of Q1 2016)
* PerfHerder
* hg.mozilla.org

== Users ==

ActiveData's primary goal is to support dashboards that give Mozilla useful perspectives into the large amount of data:

* Individual unit test results
* Buildbot test times
* Firefox compile times
* Recently new, removed, and disabled tests
* Buildbot wait times

= Let's Use It! =

The service listens at http://activedata.allizom.org/query and accepts queries in [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md JSON Query Expression format].

curl -XPOST -d "{\"from\":\"unittest\"}" http://activedata.allizom.org/query

== The Query Tool ==
The ActiveData service is intended for use by automated clients, not humans. The [http://activedata.allizom.org/tools/query.html Query Tool] is a minimal web page for humans to do some exploration, and to test phrasing queries.
* [http://activedata.allizom.org/tools/query.html ActiveData QueryTool]

== Documentation ==
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md tutorial]
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Unittest%20Schema.md Unit test results schema]
* [https://github.com/mozilla/ActiveData/blob/dev/docs/schemas_190227.md Listing of current schemas]

= Code =
Development is still in the early stages, setting up your own service
* Github: https://github.com/klahnakoski/ActiveData

= Contact =

* Kyle Lahnakoski
** IRC: ekyle@irc.mozilla.org
** Email: klahnakoski@mozilla.org
** Bugzilla: :ekyle

= More Context=
Mostly rambling, optional reading.

== Inspiration==
This project is inspired by the data warehouse and data mart technology that is common inside large corporations. These warehouses are useful because they are "active" services: This means the data is not only available, but it can be explored interactively by large audience using a query language.

== General Problem ==
A significant portion of any application is the backend database/datastore, which include:
* Managing resources and machines to support the datastore
* Data migrations on schemas during application lifetime
* Manually defining database indexes for responsive data retrieval
* Coding caching logic to reduce application latency

The manual effort put toward these features becomes significant as the amount of data grows in size and complexity. More importantly, this effort is being spent over and over on a multitude of applications, each a trivial variation of the next.

==General Solution==

Abstractly, we desire to reduce this redundant workload by adding a layer of abstraction called ActiveData: Clients using ActiveData benefit from the features it provides and avoid the datastore management complexities. While the ActiveData implementers can focus on these common issues while being given a simpler data model, and simpler query language, upon which to calculate optimizations.

Columnar datastores, have solved many (but not all) problems with changing schema. Query-directed indexing has been around for decades in Oracle's query optimization algorithms, and are available for free in ElasticSearch. We now have the technology to build an ActiveData solution.

By defining an ActiveData standard, we can innovate on both sides of the ActiveData abstraction layer independently

== Client Architecture ==

Applications that leverage an active data warehouse can forgo significant server side development, if not all, and put the logic on the client side.

EngineeringProductivity/Projects/ActiveData

2019-02-27T12:54:36Z

Klahnakoski: /* Code */ remove some misleading sections

= Overview =

ActiveData is a collection of about 8 billion records (Feb 2016) covering unit tests, Buildbot jobs, performance data, and mercurial. This collection is publicly available, and can be queried directly, similar to any database.

ActiveData is built on top of ElasticSearch, a fast, distributed, redundant document store. ActiveData provides the benefits of familiar and succinct SQL by translating SQL-like queries to ElasticSearch queries,

== Problem ==
In order to improve our testing infrastructure we require data on how that infrastructure is performing. That information can be extracted from the raw logs, but that requires downloading samples, parsing data, insertion into a database (or worse, writing queries in an imperative language, like Python). When we are done an analysis we have effectively built an ETL pipeline that does not scale, and is too specific to be reused elsewhere. The next project does this work all over again.

== Solution==
ActiveData will serve as a reusable ETL pipeline; annotating the test results with as much relevant data as possible. It also provides a query service to explore and aggregate the data, so there is minimal setup required to access this data.

= Redash =
ActiveData has a Redash connector for [https://sql.telemetry.mozilla.org/ stmo] and it accepts SQL. [https://github.com/mozilla/ActiveData/blob/dev/docs/redash.md see main doc for details]

= Charts =

ActiveData is fast enough to support dashboards.

== Build times ==
{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/End-to-End.html End to End Times]
|| Shows overall time from when a build is first requested to the time tests on that build are complete.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Overview.html Build Times]
|| Time series view of build times by platform and build type. Click on a bar to get a scatter plot view.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Detail.html Detailed Build Times]
|| Scatter plot of build times. Use the left navigation panel to choose a combination. Click on a data point to see the Buildbot step times and Mozharness step times.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Buildbot-Simulator.html Buildbot Simulator] incomplete
|| An incomplete Buildbot scheduling simulator. It can be used to see past wait times, queue size, and inter-job delays.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/index.html Test Runtimes]
|| Choose test suite and machine pool to get an average run time for each of the buildbot steps, and Mozharness steps.
|}

==Unit Test Visualization==
With all unit test results in ActiveData, we can get accurate estimates of "failure rate"; and be able to focus on the most-failing tests.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/index.html Top Intermittent Failures]
|| List of top 30 most-failing unit tests, and list of top 30 most-recent failing tests. Click on the link to get a scatterplot.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/test.html Find Test Results]
|| Use the search bar to find a test. A list of matching tests, and platform combinations will show the unit test failures and durations.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/NeglectedOranges/index.html Neglected Oranges]
|| Cross reference OrangeFactor and Bugzilla to give a list of frequent intermittents that have no bug activity.
|}

= Design =
ActiveData attempts to provide the benefits of an available database to the public; except larger and faster.

== Goals ==
An active data instance distinguishes itself from a static resource, or database, or big data solution, by delivering a particular set of features:
* '''A service, open to third party clients''' - By providing the service, clients don't need to setup their own datastore
* '''Fast filtering''' - Sub-second filtering over the contents of the whole datastore, independent of size, saves the application developer from declaring and managing indexes that do the same: There is sufficient information in the queries to determine which indexes should be built to deliver a quick response.
* '''Fast aggregates''' - Sub-second calculation of statistics over the whole datastore saves the application developer from building and managing caches of those aggregates.
* '''API is a query language (SQL?, MDX?)''' - Building upon the formalisms, and familiarity, of existing query languages, we reduce the learning curve, and also provide Active Data implementations with more insight into the intent of the client application; and optimize for its use cases.
* '''Uniform, Cartesian space of values''' - Mozilla has a mandate of data driven decision making. Data analysis tools, like Spreadsheets, R, Scipy, Numpy, and Pandas are used to perform data analysis, and they all require uniform data in multi-dimensional arrays, commonly known as "pivot tables" or "data frames". ActiveData's objective is to provide query results in these formats
* '''Metadata on dimensions and measures''' - ActiveData also provides context to the data it holds. It serves the purpose to allow exploration and discovery by third parties; by describing unit-of-measure, how dimensions relate to others, and provide human descriptions of the columns stored. This metadata is also invaluable in automating the orientation and formatting of dashboard charts: Knowing the domain of an axis allows code to decide the best (default) chart form, and provides logically reasonable aggregate options.
* '''Has a security model''' - Simpler applications can avoid the complications of a security model if it is baked into the ActiveData solution. If ActiveData is to become mainstream it is important that it can manage sensitive data and PII.

== Limitations ==

The unittest data is limited to those test suites that generate structured logs. Currently (Feb, 2016) the following do NOT have structured logs, and are NOT in ActiveData:

* cppunittest
* and any of the js based gaia suites (e.g Gij)

Specifically, you can see if a structured log is being generated: In Treeherder, click a job. Under the "Job details" pane at the bottom, look for a line similar to:

<blockquote> ''artifact uploaded: <suite>_raw.log''
</blockquote>

If you see that, it is using structured logging.

ActiveData makes specific tradeoffs to achieve its goals. It has the following limitations:
* large memory requirements
* low add/update/remove speeds
* strict data model (snowflake schema, hierarchical relations only)
* non-relational
* ETL work required to de-normalize data
* ETL work required to provide dimension metadata

== Non Goals ==
ActiveData is not meant to replace an application database. Applications often track significantly more data related to good interface design, process sequences, complex relations, and object life cycles.
ActiveData's simple model makes it difficult to track object life cycles and impossible to model many-to-many relations.
Data is not live, and definitely does not track "pending jobs" like TreeHerder or TaskCluster do. Test results may take a day, or more, to be indexed.

= Dependencies / Who will use this =
== Dependencies ==

ActiveData's ETL pipeline ingests data from a variety of sources:

* Buildbot
* Mozharness
* Structured Logs
* Task Cluster (end of Q1 2016)
* PerfHerder
* hg.mozilla.org

== Users ==

ActiveData's primary goal is to support dashboards that give Mozilla useful perspectives into the large amount of data:

* Individual unit test results
* Buildbot test times
* Firefox compile times
* Recently new, removed, and disabled tests
* Buildbot wait times

= Let's Use It! =

The service listens at http://activedata.allizom.org/query and accepts queries in [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md JSON Query Expression format].

curl -XPOST -d "{\"from\":\"unittest\"}" http://activedata.allizom.org/query

== The Query Tool ==
The ActiveData service is intended for use by automated clients, not humans. The [http://activedata.allizom.org/tools/query.html Query Tool] is a minimal web page for humans to do some exploration, and to test phrasing queries.
* [http://activedata.allizom.org/tools/query.html ActiveData QueryTool]

== Documentation ==
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md tutorial]
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Unittest%20Schema.md Unit test results schema]

= Code =
Development is still in the early stages, setting up your own service
* Github: https://github.com/klahnakoski/ActiveData

= Contact =

* Kyle Lahnakoski
** IRC: ekyle@irc.mozilla.org
** Email: klahnakoski@mozilla.org
** Bugzilla: :ekyle

= More Context=
Mostly rambling, optional reading.

== Inspiration==
This project is inspired by the data warehouse and data mart technology that is common inside large corporations. These warehouses are useful because they are "active" services: This means the data is not only available, but it can be explored interactively by large audience using a query language.

== General Problem ==
A significant portion of any application is the backend database/datastore, which include:
* Managing resources and machines to support the datastore
* Data migrations on schemas during application lifetime
* Manually defining database indexes for responsive data retrieval
* Coding caching logic to reduce application latency

The manual effort put toward these features becomes significant as the amount of data grows in size and complexity. More importantly, this effort is being spent over and over on a multitude of applications, each a trivial variation of the next.

==General Solution==

Abstractly, we desire to reduce this redundant workload by adding a layer of abstraction called ActiveData: Clients using ActiveData benefit from the features it provides and avoid the datastore management complexities. While the ActiveData implementers can focus on these common issues while being given a simpler data model, and simpler query language, upon which to calculate optimizations.

Columnar datastores, have solved many (but not all) problems with changing schema. Query-directed indexing has been around for decades in Oracle's query optimization algorithms, and are available for free in ElasticSearch. We now have the technology to build an ActiveData solution.

By defining an ActiveData standard, we can innovate on both sides of the ActiveData abstraction layer independently

== Client Architecture ==

Applications that leverage an active data warehouse can forgo significant server side development, if not all, and put the logic on the client side.

TestEngineering/Performance

2019-02-11T15:23:34Z

Klahnakoski: fix formatting

== What we do ==

== What we don't do ==

== Onboarding ==

== Objectives ==
* Increase regression detection '''coverage''' to page load on Android products including WebView comparisons
* Increase quality standards by measuring and alerting on power usage for Android and ARM64
* Build dashboards to improve '''visibility''' of how we are tracking against our release criteria for Android
* Reducing noise in test results and adding annotations to provide '''clarity''' of signal for regressions
* Develop measurements and mechanisms for reporting on our tools, policies and documentation for how to improve '''clarity''' and '''efficiency''' of risk assessments

== Team ==
* Dave Hunt [:davehunt]
* Rob Wood [:rwood]
* Kyle Lahnakoski [:ekyle]
* Stephen Donner [:stephend]
* Ionut Goldan [:igoldan]
* Florian Strugariu [:bebe]
* Greg Mierzwinski [:sparky]

== Projects ==

Trello: https://trello.com/b/gc3AlyhB/firefox-performance-test-engineering

=== Raptor ===
Raptor is a Python testing framework used to run browser benchmark and browser page-load performance tests. Raptor is cross-browser compatible and is currently running in Mozilla taskcluster production on Firefox Desktop, Firefox Android, and on Google Chromium.

* Owner: Rob Wood [:rwood]
* Source: https://searchfox.org/mozilla-central/source/testing/raptor
* Good first bugs: https://codetribute.mozilla.org/projects/automation?project%3DRaptor
* User documentation: https://wiki.mozilla.org/Performance_sheriffing/Raptor
* Developer documentation: https://wiki.mozilla.org/Performance_sheriffing/Raptor

=== Talos ===
Talos is a Python performance testing framework that is usable on Windows, Mac and Linux. Talos is our versatile performance testing framework we use at Mozilla. It was created to serve as a test runner for the existing performance tests that Mozilla was running back in 2007 as well as providing an extensible framework for new tests as they were created.

* Owner: Rob Wood [:rwood], Joel Maher [:jmaher]
* Source: https://searchfox.org/mozilla-central/source/testing/talos
* Good first bugs: https://codetribute.mozilla.org/projects/automation?project%3DTalos
* User documentation: https://wiki.mozilla.org/Performance_sheriffing/Talos
* Developer documentation: https://wiki.mozilla.org/Performance_sheriffing/Talos

=== WebPageTest ===
* Owner: Stephen Donner [:stephend]
* Source: https://github.com/mozilla/wpt-api
* (User and Dev) Docs: https://mozilla-wpt-api-docs.readthedocs.io/en/master/
* "help-wanted" labelled Issues: https://github.com/mozilla/wpt-api/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22

=== Perfherder ===

=== Firefox Are We Fast Yet Dashboard ===

Shows a variety of benchmarks, run on a variety of platforms. Meant to be a detailed view of performance.

* Location: https://arewefastyet.com
* Owner: Armen Zambrano Gasparnian [:armen]
* Source: https://github.com/mozilla-frontend-infra/firefox-performance-dashboard

=== Firefox Health Dashboard ===

The health dashboard tracks metrics and statistics important for tracking performance improvements. Meant to be a high level view.

* Location: https://health.graphics/
* Owner: Armen Zambrano Gasparnian [:armen], Kyle Lahnakoski [:ekyle]
* Source: https://github.com/mozilla-frontend-infra/firefox-health-dashboard/
* Good first bugs: https://github.com/mozilla-frontend-infra/firefox-health-dashboard/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22

TestEngineering/Performance

2019-02-11T15:22:30Z

Klahnakoski: add description of two dashbaords

== What we do ==

== What we don't do ==

== Onboarding ==

== Objectives ==
* Increase regression detection '''coverage''' to page load on Android products including WebView comparisons
* Increase quality standards by measuring and alerting on power usage for Android and ARM64
* Build dashboards to improve '''visibility''' of how we are tracking against our release criteria for Android
* Reducing noise in test results and adding annotations to provide '''clarity''' of signal for regressions
* Develop measurements and mechanisms for reporting on our tools, policies and documentation for how to improve '''clarity''' and '''efficiency''' of risk assessments

== Team ==
* Dave Hunt [:davehunt]
* Rob Wood [:rwood]
* Kyle Lahnakoski [:ekyle]
* Stephen Donner [:stephend]
* Ionut Goldan [:igoldan]
* Florian Strugariu [:bebe]
* Greg Mierzwinski [:sparky]

== Projects ==

Trello: https://trello.com/b/gc3AlyhB/firefox-performance-test-engineering

=== Raptor ===
Raptor is a Python testing framework used to run browser benchmark and browser page-load performance tests. Raptor is cross-browser compatible and is currently running in Mozilla taskcluster production on Firefox Desktop, Firefox Android, and on Google Chromium.

* Owner: Rob Wood [:rwood]
* Source: https://searchfox.org/mozilla-central/source/testing/raptor
* Good first bugs: https://codetribute.mozilla.org/projects/automation?project%3DRaptor
* User documentation: https://wiki.mozilla.org/Performance_sheriffing/Raptor
* Developer documentation: https://wiki.mozilla.org/Performance_sheriffing/Raptor

=== Talos ===
Talos is a Python performance testing framework that is usable on Windows, Mac and Linux. Talos is our versatile performance testing framework we use at Mozilla. It was created to serve as a test runner for the existing performance tests that Mozilla was running back in 2007 as well as providing an extensible framework for new tests as they were created.

* Owner: Rob Wood [:rwood], Joel Maher [:jmaher]
* Source: https://searchfox.org/mozilla-central/source/testing/talos
* Good first bugs: https://codetribute.mozilla.org/projects/automation?project%3DTalos
* User documentation: https://wiki.mozilla.org/Performance_sheriffing/Talos
* Developer documentation: https://wiki.mozilla.org/Performance_sheriffing/Talos

=== WebPageTest ===
* Owner: Stephen Donner [:stephend]
* Source: https://github.com/mozilla/wpt-api
* (User and Dev) Docs: https://mozilla-wpt-api-docs.readthedocs.io/en/master/
* "help-wanted" labelled Issues: https://github.com/mozilla/wpt-api/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22

=== Perfherder ===

=== Firefox Are We Fast Yet Dashboard ===

Shows a variety of benchmarks, run on a variety of platforms. Meant to be a detailed view of performance.

Location: https://arewefastyet.com
Owner: Armen Zambrano Gasparnian [:armen]
Source: https://github.com/mozilla-frontend-infra/firefox-performance-dashboard

=== Firefox Health Dashboard ===

The health dashboard tracks metrics and statistics important for tracking performance improvements. Meant to be a high level view.

Location: https://health.graphics/
Owner: Armen Zambrano Gasparnian [:armen], Kyle Lahnakoski [:ekyle]
Source: https://github.com/mozilla-frontend-infra/firefox-health-dashboard/
Good first bugs: https://github.com/mozilla-frontend-infra/firefox-health-dashboard/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22

Community:SummerOfCode19:Brainstorming

2019-02-05T20:21:20Z

Klahnakoski: strike some projects

Once again, Mozilla intends to apply to participate in Google's Summer Of Code.

Mozilla community members, please submit proposals here for 2019 Google Summer of Code projects with Mozilla. This page is for brainstorming - as we approach the deadline, those ideas that are accepted will be transferred to the [[Community:SummerOfCode19|official list]].)

Our application for summer of 2019 goes into Google on '''February 4th''', so get those project ideas in well ahead of time.

Are you a student looking to apply to GSoC with Mozilla? Your first stop should be the [[Community:SummerOfCode19|official list of ideas]]. This page is full of weird ideas, only some of which will make the cut. It could be that they are not properly defined, the wrong size, or don't have a mentor. That makes them less likely to get accepted. You can, of course, also submit your own ideas - you don't have to put an idea on this page and get it 'made official' in order to send in a proposal for it.

==How To Write A Good Project Proposal==

Before adding an proposal to this list, please consider the following:

* '''Be specific'''. It's hard to understand the impact of, or the size of, vague proposals.
* '''Consider size'''. The student has eight weeks to design, code, test and document the proposal. It needs to fill, but not overfill, that time.
* '''Do your research'''. Support the idea with well-researched links.
* '''Don't morph other people's ideas'''. If you have a related idea, place it next to the existing one, or add a comment.
* '''Insert only your own name into the Mentor column''', and then only if you are willing to take on the responsibility. If you think the SoC admins won't know who you are, leave contact details.
* '''Check back regularly'''. The administrators may have questions about your idea that you will need to answer.
* '''Know when to give up'''. If you've added the same idea for the last three years and it hasn't made it to the official page, perhaps you can predict what will happen this time.

==Suggestion List==

[[SummerOfCode|Here are the ideas lists from previous years]].

Proposals can be in almost any part of the Mozilla project, though they do need to be mostly focused on code.

Here are the proposals. Feel free to add a new one.

== 2019 Proposed Project List ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Additional Comments
|-
| Improve Python in the browser
| The [https://github.com/iodide-project/pyodide pyodide] project allows the Python scientific stack to run in the browser by compiling it to WebAssembly. Help make stuff run better and faster there.
| Python and JavaScript. Can learn the WebAssembly parts as you go.
| [https://mozillians.org/en-US/u/mdboom/ Michael Droettboom]
| [https://mozillians.org/en-US/u/mdboom/ Michael Droettboom]
| There are a number of specific projects we have in mind, but are open to other proposals that are within scope and seem practical within the timeframe. (1) Implement matplotlib's display on top of Web APIs (HTML5 Canvas, etc.) This would allow us to avoid shipping a whole separate rendering engine to the browser. (2) Build WebAssembly support into the conda packaging system to make it easier to distribute new compiled packages for Pyodide. (3) Make multi-dimensional arrays sharable between Python and Javascript. See Pyodide's [https://github.com/iodide-project/pyodide/issues list of issues] for additional ideas. About the mentor: Michael Droettboom is a Staff Data Engineer at Mozilla, and a former lead developer of matplotlib with years of experience building the Python scientific ecosystem.
|-
| ReSpec
| [https://github.com/w3c/respec/ ReSpec] is a JS-based tool used to write W3C Specifications (Web Standards) that is widely used by the Web Standards Community. With 6+ years of development, it's heavily depended upon by the W3C community at large (of which Mozilla is an active participant). ReSpec's code is in need of some modernization, optimizations, and bug fixes - and we could use your help! In this project, you would have the opportunity to make ReSpec's UI more accessible, making it leaner and faster using distributed processing with Web Workers, and/or adding new features to make the lives of W3C spec Editor's better.
| JavaScript, HTML, CSS.
| [https://mozillians.org/en-US/u/mcaceres/ Marcos Caceres]
| [https://mozillians.org/en-US/u/mcaceres/ Marcos Caceres]
| ReSpec offers students the opportunity to work on a large code base that has extensive real world use and impact. The project offers students an extensive range of problems to tackle, from UI design, to concurrent processing (using Web Workers to do distributed text processing), dealing with accessibility and internationalization, writing and learning about unit and integration tests, security, code review, etc. - as well as exposure to the W3C and the web standards community, this project also aims at teaching students about how web standards are put together. To determine if this is a project you would like to be part of, see the [https://github.com/w3c/respec/issues/ list of issues] you could work on. It's a great opportunity to learn about all aspects of open source software development, but with the freedom to take on small to large challenges over the Summer (depending on your skill level and level of confidence). About the mentor: Marcos Caceres is a Staff Engineer at Mozilla who has been working on Web Standards for over a decade. Marcos is the lead maintainer of ReSpec. Marcos has extensive experience mentoring developers and has previously successfully mentor a GSO student.
|-
| Ship Public Suffix List (PSL) over Remote Settings
| The list of public domain suffixes (DNS) is shipped with every release, with no way to update it on long term releases for example.
Now that Remote Settings has become a solid solution to ship data, we could use it to publish updates of the PSL.
The task consist in migrating the current client code to read from Remote Settings instead of a file, and implement a scheduled job (like Python) to push updates automatically (most likely compiled as a DAFSA file)
| JavaScript and some Python basics
| [https://mozillians.org/en-US/u/leplatrem/ Mathieu Leplatre]
| [https://mozillians.org/en-US/u/leplatrem/ Mathieu Leplatre]
| https://bugzilla.mozilla.org/show_bug.cgi?id=1083971
|-
| [https://github.com/marco-c/bugbug bugbug]
| A platform for machine learning projects applied on Bugzilla, VCS and other software development data.
| Python
| [https://github.com/marco-c Marco Castelluccio] (FIRST_NAME@mozilla.com)
| [https://github.com/marco-c Marco Castelluccio] (FIRST_NAME@mozilla.com)
| The project will involve one or more of:
i) building additional classifiers (e.g., to detect bugs with no steps to reproduce, or to suggest a developer to assign to a bug, and so on);

ii) improving accuracy/precision/recall of the existing classifiers by implementing other machine learning techniques (e.g., by using convolutional neural networks or recurrent neural networks);

iii) improving accuracy/precision/recall by implementing additional feature extraction steps or making the already existing ones better.
|-
| WebSocket Monitor
| Support for WebSocket monitoring and inspection in Firefox DevTools.
| JavaScript/React
| [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko]
| [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko]
| This project aims at providing support for WebSocket monitoring and inspection in Firefox DevTools. The feature should be built on top of the existing Network panel UI and responsible for visualizing data sent through WebSocket connection (i.e. WS frames). The user should be able to use the UI to see as well as analyse the data (search, filter, etc.).
* [https://docs.google.com/document/d/1ruHk-BA3cqzU7VHoVltnAwWt_2OXKOOAI4nTHwYllzk/edit# Detailed Project Description]
|-
| Helpful crash reporter
| The crash reporter only allows users to send crash reports but in some cases it might help the user diagnose the crash and solve it on his/her own
| C++, Javascript
| [https://mozillians.org/en-US/u/gsvelto/ Gabriele Svelto]
| [https://mozillians.org/en-US/u/gsvelto/ Gabriele Svelto]
| There's a few things that could be implemented:
* A quick test of the memory owned by the crashed process (such as those in [http://www.memtest.org/ memtest86+]) might catch faulty memory, a common cause for crashes
* The crash reporter client might try and validate Firefox files which can sometimes become corrupted (usually because of hardware issues). If they are it can prompt the user to re-install Firefox
* Many crashes are caused by buggy graphics drivers, while we blacklist the most egregious offenders we can't cover them all. The crash reporter might identify a faulty driver (if a bug for it has already been filed) and point the user to up-to-date drivers
* For crashes caused by known bugs it should be possible to point the user to the bug filed on bugzilla
|-
| Debugger Inline Variable Preview
| When the Firefox DevTools debugger is paused, users can hover over variables to get a useful tooltip that details the variable's value at that time. While this popup is very informative, one valuable enhancement would be displaying relevant contextual variables values alongside the variable inline, alleviating the need for tooltips and allowing the user to more quickly get the information they need. The applicant will work alongside the Debugger's team to implement this feature based on UX mockups and be given space to share and implement ideas of their own.
| Javascript
| [https://mozillians.org/en-US/u/davidwalsh/ David Walsh]
| [https://mozillians.org/en-US/u/davidwalsh/ David Walsh]
|
|-
| GitHub Checks Support Improvements
| [https://github.com/taskcluster/taskcluster Taskcluster] currently supports reporting results to the [https://github.com/taskcluster/taskcluster/pull/129/checks?check_run_id=54327344 GitHub Checks API], but only reports success or failure. Let's add support for showing [https://developer.github.com/v3/checks/runs/ annotations] - snippets of log output, more detailed results, images, and so on. We can even add support for additional "actions" on the task, such as re-running with debugging enabled.
| Server-side JS
| [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
| [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko], [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
|
|-
| Support GitHub Logins in Taskcluster
| [https://github.com/taskcluster/taskcluster Taskcluster] currently supports logging in with Auth0, the Mozilla login system. We would like to make it useful outside of Mozilla, and most other users do their development on GitHub, making GitHub logins a good solution. This project would involve adding support for signing in with GitHub, as well as the more challenging task of assigning appropriate permissions to users based on the setup of their GitHub account.
| Server-side JS
| [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
| [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko], [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
|
|-
| Improve Webdriver support in Servo
| [https://github.com/servo/servo/ Servo] currently supports a minimal subset of the [https://w3c.github.io/webdriver/ Webdriver standard]. We would like to improve Servo's support, and verify its correctness by passing a [https://github.com/web-platform-tests/wpt/tree/master/webdriver set of automated tests]. This project would involve writing Rust code to extend the webdriver server inside of Servo, as well as JavaScript and Python to support the [https://web-platform-tests.org/writing-tests/testdriver.html testdriver.js] testharness.
| Familiarity with Python & JavaScript; interest in learning Rust
| [https://mozillians.org/en-US/u/jdm/ Josh Bowman-Matthews]
| [https://mozillians.org/en-US/u/jdm/ Josh Bowman-Matthews]
| [https://github.com/servo/servo/wiki/Support-Webdriver-based-tests-project Project description]
|-
| Support importing Instruments profiles in perf.html
| [https://github.com/devtools-html/perf.html/ perf.html] visualizes performance data recorded from various performance analysis tools. It is a tool designed to consume performance profiles from Gecko Profiler but can visualize any profiler able to output JSON. It currently supports Gecko, Chrome and perf profile formats. Instruments is a performance analyzer that comes with Xcode. This project would involve adding support for Instruments profile import in perf.html.
| Familiarity with JavaScript & React
| [https://mozillians.org/en-US/u/canaltinova/ Nazım Can Altınova]
| [https://mozillians.org/en-US/u/canaltinova/ Nazım Can Altınova]
| https://github.com/devtools-html/perf.html/issues/1138
|-
| Common Voice - WebAssembly MP3 Encoding
| Currently Common Voice doesn’t support Safari, which is also why we have an iOS app. The only reason being the missing MediaRecorder API. It could be polyfilled (rebuilt in “userspace”) by compiling an MP3 encoder to WebAssembly. I’ve tried that a couple of times, but never had enough time to fix the opaque bugs happening in Safari. This could also be turned into its own library and would be a nice story overall of how WASM can help with WebCompat and missing APIs.
| JavaScript
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://github.com/mozilla/voice-web/issues/469 This GitHub issue] lines out some thoughts around how to implement it and you can find references to closed PRs which tried implementing it in various ways.
|-
| Common Voice - Voice Wave Avatar
| We’d like our users to have unique(ish) avatars based either on the characteristics of their voice or a visualization of how their name (or an utterance of their choosing) is pronounced. It could also be a combination of the two ideas. We’re very open to explore this space together, though the a candidate should have some knowledge in sound theory.
| JavaScript, Some knowledge of sound theory
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://mozillians.org/u/gweber/ Gregor Weber]
|-
| Tab Manager menu in Firefox
| This project will extend the tab overflow menu - which shows tabs not visible in the browser's tab strip - to allow management of all open tabs across all browser windows. The selected student will be working directly in the Firefox codebase to add functionality and new menu structures to make this easily accessible for end users.
| JavaScript, CSS, and web experience
| [https://mozillians.org/en-US/u/sfoster/ Sam Foster], [https://mozillians.org/en-US/u/bbell/ Bryan Bell]
| [https://mozillians.org/en-US/u/sfoster/ Sam Foster]
| We have [https://mozilla.invisionapp.com/share/4SNCEPDUEZ6#/screens UX mockups] for this feature, which could be broken into two phases. We also have a [https://bugzilla.mozilla.org/show_bug.cgi?id=1480542 bug on file], where discussion has begun. While working on this you will become very familiar with the Browser Toolbox, our own "Inspector" tool for the browser user-interface, as well as writing automated tests for the new feature you're adding. The existing tab overflow code lives in our [https://searchfox.org/mozilla-central/source/browser/base/content/browser-allTabsMenu.js browser-allTabsMenu.js] file, which will be the starting point for the new tab manager. You can look at this and the existing tab code to get an idea of how this currently works.
-
|-
|-
| Firefox Reader Redesign
| The design of Firefox’s Reader Mode has languished behind as Quantum has implemented the new Photon Design System. The interface needs to be rebuilt using new visual and interaction styles to match the Photon Design System.
| JavaScript, CSS, and web experience
| [https://mozillians.org/en-US/u/awallin/ Abraham Wallin]
| [https://mozillians.org/en-US/u/eeejay/ Eitan Isaacson]
| [https://mozilla.invisionapp.com/share/87N9YQYCTJZ#/315073983_Reader_View_Redesign UX Mockups] for this feature are available with visual bugs have been reported [https://bugzilla.mozilla.org/show_bug.cgi?id=1187696 here] and [https://github.com/devtools-html/ux/issues/5 here]. Functional bugs and feature enhancements have been documented [https://github.com/mozilla/readability/issues?q=is%3Aissue+is%3Aopen+label%3Areader-mode-has-issues here], [https://github.com/mozilla/readability/issues?q=is%3Aissue+is%3Aopen+label%3Ashould-be-readerable here], [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=comp%3Areader%20prod%3DToolkit%20whiteboard%3Areadability-algorithm&list_id=14539703 here], and [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=comp%3Areader%20prod%3DToolkit%20whiteboard%3Aisreadable&list_id=14539704 finally here]. The request is for an engineering student to implement the designs and tackle the queue of bugs/enhancements within the Firefox code base. Mentors will support with prioritization, design direction/assets, and technical guidance.

|-
| An Android file downloader designed for Emerging Markets
| A lesson learned thanks to our UX team is in Emerging Markets the data plan is dynamic: in late nights we have the most affordable bandwidth. Here's the question: Why not schedule big files and videos and have them downloaded when you're sleeping? The mvp would be an App which we can send urls to. After receiving these urls the App either downloads it directly or defer it to late night. As there are more and more background restrictions enforced on new Android APIs, this should be a fun and challenging journey.

A stretch goal would be to embed this downloader in our browser for Emerging Markets, Firefox Lite. Firefox Lite is not satisfied with the current Android Download Manager in several ways: We'd like to give users the ability to pause/resume a download, we'd like to download a file directly to SDcard (opposed to download it to the main storage and move it into SDcard).

We've also prepared an even more ambitious mission for those who want tough challenges: Design the app and make it dynamic deliverable. With aabs we can satisfy both light and heavy users by defaulting Android Download Manager as the download tool and prepare the aforementioned downloader dynamically so that Firefox Lite itself is still minimized in terms of disk size. Nevin and mTwTm are Android developers who can provide assistance to Android App design.
| Android Java/Kotlin
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)]
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)] (mTwTm@mozilla.com), [https://github.com/cnevinc/ Nevin Chen] (nevin@mozilla.com)
|
|-
| Toolkit for sandboxing third-parties libraries in Firefox
| Firefox supports a long tail of infrequently used image and audio formats to
support the occasional website that uses them. Each such format requires the
Firefox decoder to use a new open source library for parsing and decoding.
This, unfortunately, increases the attack surface of Firefox and as we saw in
Pwn2Own 2018, Firefox was successfully exploited via a bugs in such libraries
(libogg in this case).

This project proposes to sandbox third-party libraries in Firefox by building a
new software-fault isolation toolkit. Our tookit will build on the WebAssembly
compiler to isolate libraries in Firefox. But, as part of this toolkit we will
also develop and apply a library for safely interfacing with sandboxed libraries (and
sanitizing data coming from them). with this toolkit we can ensure that any
vulnerability in third-party libraries (e.g., libogg or libpng) cannot be used
to be used to compromise Firefox.
| C/C++, experience with WebAssembly
| [https://mozillians.org/en-US/u/erahm/ Eric Rahm]
| [https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|
|-
| Test automation our linting tools
| We have a several linting tools running on Firefox code base, they currently don't have a test suite.
The goal of this project is to make sure that tests are executed. We currently have a similar [https://bugzilla.mozilla.org/show_bug.cgi?id=1432410 test automation for static analyzer jobs]. The idea would be to extend (or replicate) this model for [https://searchfox.org/mozilla-central/source/tools/lint/ ./mach lint] (which run flake8, eslint, etc) and [https://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/mach_commands.py#2327 ./mach clang-format]
The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1448008
| Python
| [https://github.com/sylvestre Sylvestre] (s@mozilla.com)
| [https://github.com/abpostelnicu Andi Postelnicu] (andi@mozilla.com)
|
|-
| Firefox Account Security Dashboard
| Firefox Account administrators and users need an easily digestible view into the important events that have occurred on an account, providing a way to audit for irregularities.
| JavaScript, HTML, CSS, MySQL
| [https://mozillians.org/u/vbudhram/ Vijay Budhram], [https://mozillians.org/u/stomlinson/ Shane Tomlinson]
| [https://mozillians.org/u/vbudhram/ Vijay Budhram], [https://mozillians.org/u/stomlinson/ Shane Tomlinson]
| The Firefox Account platform tracks security information about an account, but does not surface this information in an easily consumable format. Users and administrators should be able to see a timeline of an account’s security related events, such as connecting devices, signing into services, changing or resetting passwords, and adding or removing 2FA. Each event in the timeline should include a timestamp, IP address, and location information when they occurred.

This project would entail updating our security event API to ensure we track and expose the required data. The first phase is to build a script that consumes the API and pretty prints the timeline. The second phase is to provide a web interface for the security timeline.

|-
| Improving FastParquet
| FastParquet is a Python library that needs improvement to how it writes the parquet file format
| Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/klahnakoski/mo-parquet/blob/dev/docs/StudentProject%202019.md Read more]

|-
| Faster Pyparsing
| Pyparsing is a Python library that provides a DSL for language specification. It could use some optimization.
| Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/moz-sql-parser/blob/dev/docs/Student%20Project%202019.md Read more]

|-
| <s>Regression Detection</s>
| <s>Use machine learning to guide statistical model selection, then use the model(s) to detect regressions in future data. </s>
| <s>Machine Learning, Statistics, Python</s>
| <s>[https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]</s>
| <s>[https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]</s>
| <s>[https://github.com/mozilla/ActiveData/blob/dev/docs/Student%20Project%20190121.md Read more]</s>

|-
| <s>Bugzilla Kanban Board</s>
| <s>Show bugs like [https://en.wikipedia.org/wiki/Post-it_Note post-it notes] on a [https://en.wikipedia.org/wiki/Whiteboard whiteboard]. Much like a [https://en.wikipedia.org/wiki/Kanban_board Kanban board]</s>
| <s>JSX/React</s>
| <s>[https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]</s>
| <s>[https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]</s>
| <s>[https://github.com/mozilla/bugzilla-tiles Read more]</s>

|-
| <s>More ActiveData Recipes</s>
| <s>Build out the user interface of the [https://github.com/mozilla/active-data-recipes active-data-recipes] project so that making new recipes is even easier</s>
| <s>JSX/React some Python</s>
| <s>[https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]</s>
| <s>[https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]</s>
| <s>[https://github.com/mozilla/active-data-recipes/pull/112/files#diff-0f126940e57c54541662345b499622f1 PR with proposal] or [https://github.com/mozilla/active-data-recipes/tree/master/docs/Student%20Project%20190130.md Read more]</s>

|-
| TUID service improvments
| The TUID service handles millions of requests daily from hundreds of machines. It must go faster, and be stabilized.
| Python/Flask/Sqlite
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [mailto:gmierzwinski@mozilla.com Gregory Mierzwinski]
| [https://github.com/mozilla/TUID/blob/dev/docs/Student%20Project%20190204.md Read more]

|-
| Firefox Source Docs Infrastructure
| Improve the infrastructure underpinning Firefox's [https://firefox-source-docs.mozilla.org/ in-tree documentation].
| Python, Sphinx, Rst
| [https://mozillians.org/en-US/u/ahal/ Andrew Halberstadt]
| [https://mozillians.org/en-US/u/ahal/ Andrew Halberstadt]
| Writing docs for Firefox's in-tree [https://firefox-source-docs.mozilla.org/ source docs] is time consuming and difficult and the end result is difficult to navigate.

With [https://developer.mozilla.org/en-US/ MDN] de-prioritizing build and workflow docs, we need a suitable replacement for all of Firefox's contribution and workflow documentation. The great advantage of documentation living in-tree, is that it can be updated along with the source. Unfortunately the current system to build and generate docs is difficult to write for, slow to build and generates poorly organized documentation. These factors discourage developers from creating or updating docs.

This project aims to improve the documentation experience via static analysis tools (e.g hint when docs might need to be updated), enabling linters, faster build times, additional language support and well structured hierarchies. Help make documentation a bigger part of our developer's day to day workflow.
|-
| Improve FixMe
| [http://fixme.ossn.club/ Improve FixMe], a tool for surfacing meaningful contribution opportunities to new contributors. This project started two years ago as a GSoC project and we are looking into adding more capabilities. The tool currently fetches issues only from GitHub and relays a lot into the tags project maintainers use in their repositories. We want to add gitlab support and come up with a more sophisticated way of identifying technologies and skills needed for new contributors
| - Backend: Go, Buffalo, Postgresql. - Front-end: React, typescript, Redux
| [https://mozillians.org/en-US/u/bacharakis/ Christos Bacharakis]
| [https://mozillians.org/en-US/u/bacharakis/ Christos Bacharakis]
| [https://github.com/ossn/fixme Link to] front-end source code, [https://github.com/ossn/fixme_backend link to backend] source code. [http://fixme.ossn.club/ FixMe tool in action]
|-
| ..your next idea here!
| some details
| skills/language
| reporter
| mentor
| comments

Community:SummerOfCode19:Brainstorming

2019-02-04T14:13:24Z

Klahnakoski: add tuid project

Once again, Mozilla intends to apply to participate in Google's Summer Of Code.

Mozilla community members, please submit proposals here for 2019 Google Summer of Code projects with Mozilla. This page is for brainstorming - as we approach the deadline, those ideas that are accepted will be transferred to the [[Community:SummerOfCode19|official list]].)

Our application for summer of 2019 goes into Google on '''February 4th''', so get those project ideas in well ahead of time.

Are you a student looking to apply to GSoC with Mozilla? Your first stop should be the [[Community:SummerOfCode19|official list of ideas]]. This page is full of weird ideas, only some of which will make the cut. It could be that they are not properly defined, the wrong size, or don't have a mentor. That makes them less likely to get accepted. You can, of course, also submit your own ideas - you don't have to put an idea on this page and get it 'made official' in order to send in a proposal for it.

==How To Write A Good Project Proposal==

Before adding an proposal to this list, please consider the following:

* '''Be specific'''. It's hard to understand the impact of, or the size of, vague proposals.
* '''Consider size'''. The student has eight weeks to design, code, test and document the proposal. It needs to fill, but not overfill, that time.
* '''Do your research'''. Support the idea with well-researched links.
* '''Don't morph other people's ideas'''. If you have a related idea, place it next to the existing one, or add a comment.
* '''Insert only your own name into the Mentor column''', and then only if you are willing to take on the responsibility. If you think the SoC admins won't know who you are, leave contact details.
* '''Check back regularly'''. The administrators may have questions about your idea that you will need to answer.
* '''Know when to give up'''. If you've added the same idea for the last three years and it hasn't made it to the official page, perhaps you can predict what will happen this time.

==Suggestion List==

[[SummerOfCode|Here are the ideas lists from previous years]].

Proposals can be in almost any part of the Mozilla project, though they do need to be mostly focused on code.

Here are the proposals. Feel free to add a new one.

== 2019 Proposed Project List ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Additional Comments
|-
| Improve Python in the browser
| The [https://github.com/iodide-project/pyodide pyodide] project allows the Python scientific stack to run in the browser by compiling it to WebAssembly. Help make stuff run better and faster there.
| Python and JavaScript. Can learn the WebAssembly parts as you go.
| [https://mozillians.org/en-US/u/mdboom/ Michael Droettboom]
| [https://mozillians.org/en-US/u/mdboom/ Michael Droettboom]
| There are a number of specific projects we have in mind, but are open to other proposals that are within scope and seem practical within the timeframe. (1) Implement matplotlib's display on top of Web APIs (HTML5 Canvas, etc.) This would allow us to avoid shipping a whole separate rendering engine to the browser. (2) Build WebAssembly support into the conda packaging system to make it easier to distribute new compiled packages for Pyodide. (3) Make multi-dimensional arrays sharable between Python and Javascript. See Pyodide's [https://github.com/iodide-project/pyodide/issues list of issues] for additional ideas. About the mentor: Michael Droettboom is a Staff Data Engineer at Mozilla, and a former lead developer of matplotlib with years of experience building the Python scientific ecosystem.
|-
| ReSpec
| [https://github.com/w3c/respec/ ReSpec] is a JS-based tool used to write W3C Specifications (Web Standards) that is widely used by the Web Standards Community. With 6+ years of development, it's heavily depended upon by the W3C community at large (of which Mozilla is an active participant). ReSpec's code is in need of some modernization, optimizations, and bug fixes - and we could use your help! In this project, you would have the opportunity to make ReSpec's UI more accessible, making it leaner and faster using distributed processing with Web Workers, and/or adding new features to make the lives of W3C spec Editor's better.
| JavaScript, HTML, CSS.
| [https://mozillians.org/en-US/u/mcaceres/ Marcos Caceres]
| [https://mozillians.org/en-US/u/mcaceres/ Marcos Caceres]
| ReSpec offers students the opportunity to work on a large code base that has extensive real world use and impact. The project offers students an extensive range of problems to tackle, from UI design, to concurrent processing (using Web Workers to do distributed text processing), dealing with accessibility and internationalization, writing and learning about unit and integration tests, security, code review, etc. - as well as exposure to the W3C and the web standards community, this project also aims at teaching students about how web standards are put together. To determine if this is a project you would like to be part of, see the [https://github.com/w3c/respec/issues/ list of issues] you could work on. It's a great opportunity to learn about all aspects of open source software development, but with the freedom to take on small to large challenges over the Summer (depending on your skill level and level of confidence). About the mentor: Marcos Caceres is a Staff Engineer at Mozilla who has been working on Web Standards for over a decade. Marcos is the lead maintainer of ReSpec. Marcos has extensive experience mentoring developers and has previously successfully mentor a GSO student.
|-
| Ship Public Suffix List (PSL) over Remote Settings
| The list of public domain suffixes (DNS) is shipped with every release, with no way to update it on long term releases for example.
Now that Remote Settings has become a solid solution to ship data, we could use it to publish updates of the PSL.
The task consist in migrating the current client code to read from Remote Settings instead of a file, and implement a scheduled job (like Python) to push updates automatically (most likely compiled as a DAFSA file)
| JavaScript and some Python basics
| [https://mozillians.org/en-US/u/leplatrem/ Mathieu Leplatre]
| [https://mozillians.org/en-US/u/leplatrem/ Mathieu Leplatre]
| https://bugzilla.mozilla.org/show_bug.cgi?id=1083971
|-
| [https://github.com/marco-c/bugbug bugbug]
| A platform for machine learning projects applied on Bugzilla, VCS and other software development data.
| Python
| [https://github.com/marco-c Marco Castelluccio] (FIRST_NAME@mozilla.com)
| [https://github.com/marco-c Marco Castelluccio] (FIRST_NAME@mozilla.com)
| The project will involve one or more of:
i) building additional classifiers (e.g., to detect bugs with no steps to reproduce, or to suggest a developer to assign to a bug, and so on);

ii) improving accuracy/precision/recall of the existing classifiers by implementing other machine learning techniques (e.g., by using convolutional neural networks or recurrent neural networks);

iii) improving accuracy/precision/recall by implementing additional feature extraction steps or making the already existing ones better.
|-
| Make the Firefox WebAuthn Soft Token a Real Thing
| The Web Authentication Soft Token provides second-factor login support without needing a Security Key dongle. It would be very usable if the Soft Token were a) synchronized across an account using Sync, b) could be controlled via a Web Extension, and perhaps c) had some UI. If these things were true, most people could get quality authentication support without buying another device.
| C++, Javascript, Basic cryptography
| [https://mozillians.org/en-US/u/jcjones/ J.C. Jones]
| [https://mozillians.org/en-US/u/jcjones/ J.C. Jones]
| https://wiki.mozilla.org/Security/CryptoEngineering#Web_Authentication
|-
| WebSocket Monitor
| Support for WebSocket monitoring and inspection in Firefox DevTools.
| JavaScript/React
| [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko]
| [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko]
| This project aims at providing support for WebSocket monitoring and inspection in Firefox DevTools. The feature should be built on top of the existing Network panel UI and responsible for visualizing data sent through WebSocket connection (i.e. WS frames). The user should be able to use the UI to see as well as analyse the data (search, filter, etc.).
* [https://docs.google.com/document/d/1ruHk-BA3cqzU7VHoVltnAwWt_2OXKOOAI4nTHwYllzk/edit# Detailed Project Description]
|-
| Helpful crash reporter
| The crash reporter only allows users to send crash reports but in some cases it might help the user diagnose the crash and solve it on his/her own
| C++, Javascript
| [https://mozillians.org/en-US/u/gsvelto/ Gabriele Svelto]
| [https://mozillians.org/en-US/u/gsvelto/ Gabriele Svelto]
| There's a few things that could be implemented:
* A quick test of the memory owned by the crashed process (such as those in [http://www.memtest.org/ memtest86+]) might catch faulty memory, a common cause for crashes
* The crash reporter client might try and validate Firefox files which can sometimes become corrupted (usually because of hardware issues). If they are it can prompt the user to re-install Firefox
* Many crashes are caused by buggy graphics drivers, while we blacklist the most egregious offenders we can't cover them all. The crash reporter might identify a faulty driver (if a bug for it has already been filed) and point the user to up-to-date drivers
* For crashes caused by known bugs it should be possible to point the user to the bug filed on bugzilla
|-
| Debugger Inline Variable Preview
| When the Firefox DevTools debugger is paused, users can hover over variables to get a useful tooltip that details the variable's value at that time. While this popup is very informative, one valuable enhancement would be displaying relevant contextual variables values alongside the variable inline, alleviating the need for tooltips and allowing the user to more quickly get the information they need. The applicant will work alongside the Debugger's team to implement this feature based on UX mockups and be given space to share and implement ideas of their own.
| Javascript
| [https://mozillians.org/en-US/u/davidwalsh/ David Walsh]
| [https://mozillians.org/en-US/u/davidwalsh/ David Walsh]
|
|-
| GitHub Checks Support Improvements
| [https://github.com/taskcluster/taskcluster Taskcluster] currently supports reporting results to the [https://github.com/taskcluster/taskcluster/pull/129/checks?check_run_id=54327344 GitHub Checks API], but only reports success or failure. Let's add support for showing [https://developer.github.com/v3/checks/runs/ annotations] - snippets of log output, more detailed results, images, and so on. We can even add support for additional "actions" on the task, such as re-running with debugging enabled.
| Server-side JS
| [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
| [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko], [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
|
|-
| Support GitHub Logins in Taskcluster
| [https://github.com/taskcluster/taskcluster Taskcluster] currently supports logging in with Auth0, the Mozilla login system. We would like to make it useful outside of Mozilla, and most other users do their development on GitHub, making GitHub logins a good solution. This project would involve adding support for signing in with GitHub, as well as the more challenging task of assigning appropriate permissions to users based on the setup of their GitHub account.
| Server-side JS
| [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
| [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko], [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
|
|-
| Improve Webdriver support in Servo
| [https://github.com/servo/servo/ Servo] currently supports a minimal subset of the [https://w3c.github.io/webdriver/ Webdriver standard]. We would like to improve Servo's support, and verify its correctness by passing a [https://github.com/web-platform-tests/wpt/tree/master/webdriver set of automated tests]. This project would involve writing Rust code to extend the webdriver server inside of Servo, as well as JavaScript and Python to support the [https://web-platform-tests.org/writing-tests/testdriver.html testdriver.js] testharness.
| Familiarity with Python & JavaScript; interest in learning Rust
| [https://mozillians.org/en-US/u/jdm/ Josh Bowman-Matthews]
| [https://mozillians.org/en-US/u/jdm/ Josh Bowman-Matthews]
| [https://github.com/servo/servo/wiki/Support-Webdriver-based-tests-project Project description]
|-
| Support importing Instruments profiles in perf.html
| [https://github.com/devtools-html/perf.html/ perf.html] visualizes performance data recorded from various performance analysis tools. It is a tool designed to consume performance profiles from Gecko Profiler but can visualize any profiler able to output JSON. It currently supports Gecko, Chrome and perf profile formats. Instruments is a performance analyzer that comes with Xcode. This project would involve adding support for Instruments profile import in perf.html.
| Familiarity with JavaScript & React
| [https://mozillians.org/en-US/u/canaltinova/ Nazım Can Altınova]
| [https://mozillians.org/en-US/u/canaltinova/ Nazım Can Altınova]
| https://github.com/devtools-html/perf.html/issues/1138
|-
| Common Voice - WebAssembly MP3 Encoding
| Currently Common Voice doesn’t support Safari, which is also why we have an iOS app. The only reason being the missing MediaRecorder API. It could be polyfilled (rebuilt in “userspace”) by compiling an MP3 encoder to WebAssembly. I’ve tried that a couple of times, but never had enough time to fix the opaque bugs happening in Safari. This could also be turned into its own library and would be a nice story overall of how WASM can help with WebCompat and missing APIs.
| JavaScript
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://github.com/mozilla/voice-web/issues/469 This GitHub issue] lines out some thoughts around how to implement it and you can find references to closed PRs which tried implementing it in various ways.
|-
| Common Voice - Voice Wave Avatar
| We’d like our users to have unique(ish) avatars based either on the characteristics of their voice or a visualization of how their name (or an utterance of their choosing) is pronounced. It could also be a combination of the two ideas. We’re very open to explore this space together, though the a candidate should have some knowledge in sound theory.
| JavaScript, Some knowledge of sound theory
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://mozillians.org/u/gweber/ Gregor Weber]
|-
| Tab Manager menu in Firefox
| This project will extend the tab overflow menu - which shows tabs not visible in the browser's tab strip - to allow management of all open tabs across all browser windows. The selected student will be working directly in the Firefox codebase to add functionality and new menu structures to make this easily accessible for end users.
| JavaScript, CSS, and web experience
| [https://mozillians.org/en-US/u/sfoster/ Sam Foster], [https://mozillians.org/en-US/u/bbell/ Bryan Bell]
| [https://mozillians.org/en-US/u/sfoster/ Sam Foster]
| We have [https://mozilla.invisionapp.com/share/4SNCEPDUEZ6#/screens UX mockups] for this feature, which could be broken into two phases. We also have a [https://bugzilla.mozilla.org/show_bug.cgi?id=1480542 bug on file], where discussion has begun. While working on this you will become very familiar with the Browser Toolbox, our own "Inspector" tool for the browser user-interface, as well as writing automated tests for the new feature you're adding. The existing tab overflow code lives in our [https://searchfox.org/mozilla-central/source/browser/base/content/browser-allTabsMenu.js browser-allTabsMenu.js] file, which will be the starting point for the new tab manager. You can look at this and the existing tab code to get an idea of how this currently works.
-
|-
|-
| Firefox Reader Redesign
| The design of Firefox’s Reader Mode has languished behind as Quantum has implemented the new Photon Design System. The interface needs to be rebuilt using new visual and interaction styles to match the Photon Design System.
| JavaScript, CSS, and web experience
| [https://mozillians.org/en-US/u/awallin/ Abraham Wallin]
| [https://mozillians.org/en-US/u/eeejay/ Eitan Isaacson]
| [https://mozilla.invisionapp.com/share/87N9YQYCTJZ#/315073983_Reader_View_Redesign UX Mockups] for this feature are available with visual bugs have been reported [https://bugzilla.mozilla.org/show_bug.cgi?id=1187696 here] and [https://github.com/devtools-html/ux/issues/5 here]. Functional bugs and feature enhancements have been documented [https://github.com/mozilla/readability/issues?q=is%3Aissue+is%3Aopen+label%3Areader-mode-has-issues here], [https://github.com/mozilla/readability/issues?q=is%3Aissue+is%3Aopen+label%3Ashould-be-readerable here], [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=comp%3Areader%20prod%3DToolkit%20whiteboard%3Areadability-algorithm&list_id=14539703 here], and [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=comp%3Areader%20prod%3DToolkit%20whiteboard%3Aisreadable&list_id=14539704 finally here]. The request is for an engineering student to implement the designs and tackle the queue of bugs/enhancements within the Firefox code base. Mentors will support with prioritization, design direction/assets, and technical guidance.

|-
| An Android file downloader designed for Emerging Markets
| A lesson learned thanks to our UX team is in Emerging Markets the data plan is dynamic: in late nights we have the most affordable bandwidth. Here's the question: Why not schedule big files and videos and have them downloaded when you're sleeping? The mvp would be an App which we can send urls to. After receiving these urls the App either downloads it directly or defer it to late night. As there are more and more background restrictions enforced on new Android APIs, this should be a fun and challenging journey.

A stretch goal would be to embed this downloader in our browser for Emerging Markets, Firefox Lite. Firefox Lite is not satisfied with the current Android Download Manager in several ways: We'd like to give users the ability to pause/resume a download, we'd like to download a file directly to SDcard (opposed to download it to the main storage and move it into SDcard).

We've also prepared an even more ambitious mission for those who want tough challenges: Design the app and make it dynamic deliverable. With aabs we can satisfy both light and heavy users by defaulting Android Download Manager as the download tool and prepare the aforementioned downloader dynamically so that Firefox Lite itself is still minimized in terms of disk size. Nevin and mTwTm are Android developers who can provide assistance to Android App design.
| Android Java/Kotlin
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)]
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)] (mTwTm@mozilla.com), [https://github.com/cnevinc/ Nevin Chen] (nevin@mozilla.com)
|
|-
| Toolkit for sandboxing third-parties libraries in Firefox
| Firefox supports a long tail of infrequently used image and audio formats to
support the occasional website that uses them. Each such format requires the
Firefox decoder to use a new open source library for parsing and decoding.
This, unfortunately, increases the attack surface of Firefox and as we saw in
Pwn2Own 2018, Firefox was successfully exploited via a bugs in such libraries
(libogg in this case).

This project proposes to sandbox third-party libraries in Firefox by building a
new software-fault isolation toolkit. Our tookit will build on the WebAssembly
compiler to isolate libraries in Firefox. But, as part of this toolkit we will
also develop and apply a library for safely interfacing with sandboxed libraries (and
sanitizing data coming from them). with this toolkit we can ensure that any
vulnerability in third-party libraries (e.g., libogg or libpng) cannot be used
to be used to compromise Firefox.
| C/C++, experience with WebAssembly
| [https://mozillians.org/en-US/u/erahm/ Eric Rahm]
| [https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|
|-
| Test automation our linting tools
| We have a several linting tools running on Firefox code base, they currently don't have a test suite.
The goal of this project is to make sure that tests are executed. We currently have a similar [https://bugzilla.mozilla.org/show_bug.cgi?id=1432410 test automation for static analyzer jobs]. The idea would be to extend (or replicate) this model for [https://searchfox.org/mozilla-central/source/tools/lint/ ./mach lint] (which run flake8, eslint, etc) and [https://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/mach_commands.py#2327 ./mach clang-format]
The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1448008
| Python
| [https://github.com/sylvestre Sylvestre] (s@mozilla.com)
| [https://github.com/abpostelnicu Andi Postelnicu] (andi@mozilla.com)
|
|-
| Firefox Account Security Dashboard
| Firefox Account administrators and users need an easily digestible view into the important events that have occurred on an account, providing a way to audit for irregularities.
| JavaScript, HTML, CSS, MySQL
| [https://mozillians.org/u/vbudhram/ Vijay Budhram], [https://mozillians.org/u/stomlinson/ Shane Tomlinson]
| [https://mozillians.org/u/vbudhram/ Vijay Budhram], [https://mozillians.org/u/stomlinson/ Shane Tomlinson]
| The Firefox Account platform tracks security information about an account, but does not surface this information in an easily consumable format. Users and administrators should be able to see a timeline of an account’s security related events, such as connecting devices, signing into services, changing or resetting passwords, and adding or removing 2FA. Each event in the timeline should include a timestamp, IP address, and location information when they occurred.

This project would entail updating our security event API to ensure we track and expose the required data. The first phase is to build a script that consumes the API and pretty prints the timeline. The second phase is to provide a web interface for the security timeline.

|-
| Improving FastParquet
| FastParquet is a Python library that needs improvement to how it writes the parquet file format
| Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/klahnakoski/mo-parquet/blob/dev/docs/StudentProject%202019.md Read more]

|-
| Faster Pyparsing
| Pyparsing is a Python library that provides a DSL for language specification. It could use some optimization.
| Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/moz-sql-parser/blob/dev/docs/Student%20Project%202019.md Read more]

|-
| Regression Detection
| Use machine learning to guide statistical model selection, then use the model(s) to detect regressions in future data.
| Machine Learning, Statistics, Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/ActiveData/blob/dev/docs/Student%20Project%20190121.md Read more]

|-
| Bugzilla Kanban Board
| Show bugs like [https://en.wikipedia.org/wiki/Post-it_Note post-it notes] on a [https://en.wikipedia.org/wiki/Whiteboard whiteboard]. Much like a [https://en.wikipedia.org/wiki/Kanban_board Kanban board]
| JSX/React
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/bugzilla-tiles Read more]

|-
| More ActiveData Recipes
| Build out the user interface of the [https://github.com/mozilla/active-data-recipes active-data-recipes] project so that making new recipes is even easier
| JSX/React some Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ahal/ Andrew Halberstadt]
| [https://github.com/mozilla/active-data-recipes/pull/112/files#diff-0f126940e57c54541662345b499622f1 PR with proposal] or [https://github.com/mozilla/active-data-recipes/tree/master/docs/Student%20Project%20190130.md Read more]

|-
| TUID service improvments
| The TUID service handles millions of requests daily from hundreds of machines. It must go faster, and be stabilized.
| Python/Flask/Sqlite
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [mailto:gmierzwinski@mozilla.com Gregory Mierzwinski]
| [https://github.com/mozilla/TUID/blob/dev/docs/Student%20Project%20190204.md Read more]

|-
| ..your next idea here!
| some details
| skills/language
| reporter
| mentor
| comments

Community:SummerOfCode19:Brainstorming

2019-02-03T17:42:33Z

Klahnakoski: add project

Once again, Mozilla intends to apply to participate in Google's Summer Of Code.

Mozilla community members, please submit proposals here for 2019 Google Summer of Code projects with Mozilla. This page is for brainstorming - as we approach the deadline, those ideas that are accepted will be transferred to the [[Community:SummerOfCode19|official list]].)

Our application for summer of 2019 goes into Google on '''February 4th''', so get those project ideas in well ahead of time.

Are you a student looking to apply to GSoC with Mozilla? Your first stop should be the [[Community:SummerOfCode19|official list of ideas]]. This page is full of weird ideas, only some of which will make the cut. It could be that they are not properly defined, the wrong size, or don't have a mentor. That makes them less likely to get accepted. You can, of course, also submit your own ideas - you don't have to put an idea on this page and get it 'made official' in order to send in a proposal for it.

==How To Write A Good Project Proposal==

Before adding an proposal to this list, please consider the following:

* '''Be specific'''. It's hard to understand the impact of, or the size of, vague proposals.
* '''Consider size'''. The student has eight weeks to design, code, test and document the proposal. It needs to fill, but not overfill, that time.
* '''Do your research'''. Support the idea with well-researched links.
* '''Don't morph other people's ideas'''. If you have a related idea, place it next to the existing one, or add a comment.
* '''Insert only your own name into the Mentor column''', and then only if you are willing to take on the responsibility. If you think the SoC admins won't know who you are, leave contact details.
* '''Check back regularly'''. The administrators may have questions about your idea that you will need to answer.
* '''Know when to give up'''. If you've added the same idea for the last three years and it hasn't made it to the official page, perhaps you can predict what will happen this time.

==Suggestion List==

[[SummerOfCode|Here are the ideas lists from previous years]].

Proposals can be in almost any part of the Mozilla project, though they do need to be mostly focused on code.

Here are the proposals. Feel free to add a new one.

== 2019 Proposed Project List ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Additional Comments
|-
| Improve Python in the browser
| The [https://github.com/iodide-project/pyodide pyodide] project allows the Python scientific stack to run in the browser by compiling it to WebAssembly. Help make stuff run better and faster there.
| Python and JavaScript. Can learn the WebAssembly parts as you go.
| [https://mozillians.org/en-US/u/mdboom/ Michael Droettboom]
| [https://mozillians.org/en-US/u/mdboom/ Michael Droettboom]
| There are a number of specific projects we have in mind, but are open to other proposals that are within scope and seem practical within the timeframe. (1) Implement matplotlib's display on top of Web APIs (HTML5 Canvas, etc.) This would allow us to avoid shipping a whole separate rendering engine to the browser. (2) Build WebAssembly support into the conda packaging system to make it easier to distribute new compiled packages for Pyodide. (3) Make multi-dimensional arrays sharable between Python and Javascript. See Pyodide's [https://github.com/iodide-project/pyodide/issues list of issues] for additional ideas. About the mentor: Michael Droettboom is a Staff Data Engineer at Mozilla, and a former lead developer of matplotlib with years of experience building the Python scientific ecosystem.
|-
| ReSpec
| [https://github.com/w3c/respec/ ReSpec] is a JS-based tool used to write W3C Specifications (Web Standards) that is widely used by the Web Standards Community. With 6+ years of development, it's heavily depended upon by the W3C community at large (of which Mozilla is an active participant). ReSpec's code is in need of some modernization, optimizations, and bug fixes - and we could use your help! In this project, you would have the opportunity to make ReSpec's UI more accessible, making it leaner and faster using distributed processing with Web Workers, and/or adding new features to make the lives of W3C spec Editor's better.
| JavaScript, HTML, CSS.
| [https://mozillians.org/en-US/u/mcaceres/ Marcos Caceres]
| [https://mozillians.org/en-US/u/mcaceres/ Marcos Caceres]
| ReSpec offers students the opportunity to work on a large code base that has extensive real world use and impact. The project offers students an extensive range of problems to tackle, from UI design, to concurrent processing (using Web Workers to do distributed text processing), dealing with accessibility and internationalization, writing and learning about unit and integration tests, security, code review, etc. - as well as exposure to the W3C and the web standards community, this project also aims at teaching students about how web standards are put together. To determine if this is a project you would like to be part of, see the [https://github.com/w3c/respec/issues/ list of issues] you could work on. It's a great opportunity to learn about all aspects of open source software development, but with the freedom to take on small to large challenges over the Summer (depending on your skill level and level of confidence). About the mentor: Marcos Caceres is a Staff Engineer at Mozilla who has been working on Web Standards for over a decade. Marcos is the lead maintainer of ReSpec. Marcos has extensive experience mentoring developers and has previously successfully mentor a GSO student.
|-
| Ship Public Suffix List (PSL) over Remote Settings
| The list of public domain suffixes (DNS) is shipped with every release, with no way to update it on long term releases for example.
Now that Remote Settings has become a solid solution to ship data, we could use it to publish updates of the PSL.
The task consist in migrating the current client code to read from Remote Settings instead of a file, and implement a scheduled job (like Python) to push updates automatically (most likely compiled as a DAFSA file)
| JavaScript and some Python basics
| [https://mozillians.org/en-US/u/leplatrem/ Mathieu Leplatre]
| [https://mozillians.org/en-US/u/leplatrem/ Mathieu Leplatre]
| https://bugzilla.mozilla.org/show_bug.cgi?id=1083971
|-
| [https://github.com/marco-c/bugbug bugbug]
| A platform for machine learning projects applied on Bugzilla, VCS and other software development data.
| Python
| [https://github.com/marco-c Marco Castelluccio] (FIRST_NAME@mozilla.com)
| [https://github.com/marco-c Marco Castelluccio] (FIRST_NAME@mozilla.com)
| The project will involve one or more of:
i) building additional classifiers (e.g., to detect bugs with no steps to reproduce, or to suggest a developer to assign to a bug, and so on);

ii) improving accuracy/precision/recall of the existing classifiers by implementing other machine learning techniques (e.g., by using convolutional neural networks or recurrent neural networks);

iii) improving accuracy/precision/recall by implementing additional feature extraction steps or making the already existing ones better.
|-
| Make the Firefox WebAuthn Soft Token a Real Thing
| The Web Authentication Soft Token provides second-factor login support without needing a Security Key dongle. It would be very usable if the Soft Token were a) synchronized across an account using Sync, b) could be controlled via a Web Extension, and perhaps c) had some UI. If these things were true, most people could get quality authentication support without buying another device.
| C++, Javascript, Basic cryptography
| [https://mozillians.org/en-US/u/jcjones/ J.C. Jones]
| [https://mozillians.org/en-US/u/jcjones/ J.C. Jones]
| https://wiki.mozilla.org/Security/CryptoEngineering#Web_Authentication
|-
| WebSocket Monitor
| Support for WebSocket monitoring and inspection in Firefox DevTools.
| JavaScript/React
| [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko]
| [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko]
| This project aims at providing support for WebSocket monitoring and inspection in Firefox DevTools. The feature should be built on top of the existing Network panel UI and responsible for visualizing data sent through WebSocket connection (i.e. WS frames). The user should be able to use the UI to see as well as analyse the data (search, filter, etc.).
* [https://docs.google.com/document/d/1ruHk-BA3cqzU7VHoVltnAwWt_2OXKOOAI4nTHwYllzk/edit# Detailed Project Description]
|-
| Helpful crash reporter
| The crash reporter only allows users to send crash reports but in some cases it might help the user diagnose the crash and solve it on his/her own
| C++, Javascript
| [https://mozillians.org/en-US/u/gsvelto/ Gabriele Svelto]
| [https://mozillians.org/en-US/u/gsvelto/ Gabriele Svelto]
| There's a few things that could be implemented:
* A quick test of the memory owned by the crashed process (such as those in [http://www.memtest.org/ memtest86+]) might catch faulty memory, a common cause for crashes
* The crash reporter client might try and validate Firefox files which can sometimes become corrupted (usually because of hardware issues). If they are it can prompt the user to re-install Firefox
* Many crashes are caused by buggy graphics drivers, while we blacklist the most egregious offenders we can't cover them all. The crash reporter might identify a faulty driver (if a bug for it has already been filed) and point the user to up-to-date drivers
* For crashes caused by known bugs it should be possible to point the user to the bug filed on bugzilla
|-
| Debugger Inline Variable Preview
| When the Firefox DevTools debugger is paused, users can hover over variables to get a useful tooltip that details the variable's value at that time. While this popup is very informative, one valuable enhancement would be displaying relevant contextual variables values alongside the variable inline, alleviating the need for tooltips and allowing the user to more quickly get the information they need. The applicant will work alongside the Debugger's team to implement this feature based on UX mockups and be given space to share and implement ideas of their own.
| Javascript
| [https://mozillians.org/en-US/u/davidwalsh/ David Walsh]
| [https://mozillians.org/en-US/u/davidwalsh/ David Walsh]
|
|-
| GitHub Checks Support Improvements
| [https://github.com/taskcluster/taskcluster Taskcluster] currently supports reporting results to the [https://github.com/taskcluster/taskcluster/pull/129/checks?check_run_id=54327344 GitHub Checks API], but only reports success or failure. Let's add support for showing [https://developer.github.com/v3/checks/runs/ annotations] - snippets of log output, more detailed results, images, and so on. We can even add support for additional "actions" on the task, such as re-running with debugging enabled.
| Server-side JS
| [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
| [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko], [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
|
|-
| Support GitHub Logins in Taskcluster
| [https://github.com/taskcluster/taskcluster Taskcluster] currently supports logging in with Auth0, the Mozilla login system. We would like to make it useful outside of Mozilla, and most other users do their development on GitHub, making GitHub logins a good solution. This project would involve adding support for signing in with GitHub, as well as the more challenging task of assigning appropriate permissions to users based on the setup of their GitHub account.
| Server-side JS
| [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
| [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko], [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
|
|-
| Improve Webdriver support in Servo
| [https://github.com/servo/servo/ Servo] currently supports a minimal subset of the [https://w3c.github.io/webdriver/ Webdriver standard]. We would like to improve Servo's support, and verify its correctness by passing a [https://github.com/web-platform-tests/wpt/tree/master/webdriver set of automated tests]. This project would involve writing Rust code to extend the webdriver server inside of Servo, as well as JavaScript and Python to support the [https://web-platform-tests.org/writing-tests/testdriver.html testdriver.js] testharness.
| Familiarity with Python & JavaScript; interest in learning Rust
| [https://mozillians.org/en-US/u/jdm/ Josh Bowman-Matthews]
| [https://mozillians.org/en-US/u/jdm/ Josh Bowman-Matthews]
| [https://github.com/servo/servo/wiki/Support-Webdriver-based-tests-project Project description]
|-
| Support importing Instruments profiles in perf.html
| [https://github.com/devtools-html/perf.html/ perf.html] visualizes performance data recorded from various performance analysis tools. It is a tool designed to consume performance profiles from Gecko Profiler but can visualize any profiler able to output JSON. It currently supports Gecko, Chrome and perf profile formats. Instruments is a performance analyzer that comes with Xcode. This project would involve adding support for Instruments profile import in perf.html.
| Familiarity with JavaScript & React
| [https://mozillians.org/en-US/u/canaltinova/ Nazım Can Altınova]
| [https://mozillians.org/en-US/u/canaltinova/ Nazım Can Altınova]
| https://github.com/devtools-html/perf.html/issues/1138
|-
| Common Voice - WebAssembly MP3 Encoding
| Currently Common Voice doesn’t support Safari, which is also why we have an iOS app. The only reason being the missing MediaRecorder API. It could be polyfilled (rebuilt in “userspace”) by compiling an MP3 encoder to WebAssembly. I’ve tried that a couple of times, but never had enough time to fix the opaque bugs happening in Safari. This could also be turned into its own library and would be a nice story overall of how WASM can help with WebCompat and missing APIs.
| JavaScript
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://github.com/mozilla/voice-web/issues/469 This GitHub issue] lines out some thoughts around how to implement it and you can find references to closed PRs which tried implementing it in various ways.
|-
| Common Voice - Voice Wave Avatar
| We’d like our users to have unique(ish) avatars based either on the characteristics of their voice or a visualization of how their name (or an utterance of their choosing) is pronounced. It could also be a combination of the two ideas. We’re very open to explore this space together, though the a candidate should have some knowledge in sound theory.
| JavaScript, Some knowledge of sound theory
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://mozillians.org/u/gweber/ Gregor Weber]
|-
| Tab Manager menu in Firefox
| This project will extend the tab overflow menu - which shows tabs not visible in the browser's tab strip - to allow management of all open tabs across all browser windows. The selected student will be working directly in the Firefox codebase to add functionality and new menu structures to make this easily accessible for end users.
| JavaScript, CSS, and web experience
| [https://mozillians.org/en-US/u/sfoster/ Sam Foster], [https://mozillians.org/en-US/u/bbell/ Bryan Bell]
| [https://mozillians.org/en-US/u/sfoster/ Sam Foster]
| We have [https://mozilla.invisionapp.com/share/4SNCEPDUEZ6#/screens UX mockups] for this feature, which could be broken into two phases. We also have a [https://bugzilla.mozilla.org/show_bug.cgi?id=1480542 bug on file], where discussion has begun. While working on this you will become very familiar with the Browser Toolbox, our own "Inspector" tool for the browser user-interface, as well as writing automated tests for the new feature you're adding. The existing tab overflow code lives in our [https://searchfox.org/mozilla-central/source/browser/base/content/browser-allTabsMenu.js browser-allTabsMenu.js] file, which will be the starting point for the new tab manager. You can look at this and the existing tab code to get an idea of how this currently works.
-
|-
|-
| Firefox Reader Redesign
| The design of Firefox’s Reader Mode has languished behind as Quantum has implemented the new Photon Design System. The interface needs to be rebuilt using new visual and interaction styles to match the Photon Design System.
| JavaScript, CSS, and web experience
| [https://mozillians.org/en-US/u/awallin/ Abraham Wallin]
| [https://mozillians.org/en-US/u/eeejay/ Eitan Isaacson]
| [https://mozilla.invisionapp.com/share/87N9YQYCTJZ#/315073983_Reader_View_Redesign UX Mockups] for this feature are available with visual bugs have been reported [https://bugzilla.mozilla.org/show_bug.cgi?id=1187696 here] and [https://github.com/devtools-html/ux/issues/5 here]. Functional bugs and feature enhancements have been documented [https://github.com/mozilla/readability/issues?q=is%3Aissue+is%3Aopen+label%3Areader-mode-has-issues here], [https://github.com/mozilla/readability/issues?q=is%3Aissue+is%3Aopen+label%3Ashould-be-readerable here], [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=comp%3Areader%20prod%3DToolkit%20whiteboard%3Areadability-algorithm&list_id=14539703 here], and [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=comp%3Areader%20prod%3DToolkit%20whiteboard%3Aisreadable&list_id=14539704 finally here]. The request is for an engineering student to implement the designs and tackle the queue of bugs/enhancements within the Firefox code base. Mentors will support with prioritization, design direction/assets, and technical guidance.

|-
| An Android file downloader designed for Emerging Markets
| A lesson learned thanks to our UX team is in Emerging Markets the data plan is dynamic: in late nights we have the most affordable bandwidth. Here's the question: Why not schedule big files and videos and have them downloaded when you're sleeping? The mvp would be an App which we can send urls to. After receiving these urls the App either downloads it directly or defer it to late night. As there are more and more background restrictions enforced on new Android APIs, this should be a fun and challenging journey.

A stretch goal would be to embed this downloader in our browser for Emerging Markets, Firefox Lite. Firefox Lite is not satisfied with the current Android Download Manager in several ways: We'd like to give users the ability to pause/resume a download, we'd like to download a file directly to SDcard (opposed to download it to the main storage and move it into SDcard).

We've also prepared an even more ambitious mission for those who want tough challenges: Design the app and make it dynamic deliverable. With aabs we can satisfy both light and heavy users by defaulting Android Download Manager as the download tool and prepare the aforementioned downloader dynamically so that Firefox Lite itself is still minimized in terms of disk size. Nevin and mTwTm are Android developers who can provide assistance to Android App design.
| Android Java/Kotlin
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)]
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)] (mTwTm@mozilla.com), [https://github.com/cnevinc/ Nevin Chen] (nevin@mozilla.com)
|
|-
| Toolkit for sandboxing third-parties libraries in Firefox
| Firefox supports a long tail of infrequently used image and audio formats to
support the occasional website that uses them. Each such format requires the
Firefox decoder to use a new open source library for parsing and decoding.
This, unfortunately, increases the attack surface of Firefox and as we saw in
Pwn2Own 2018, Firefox was successfully exploited via a bugs in such libraries
(libogg in this case).

This project proposes to sandbox third-party libraries in Firefox by building a
new software-fault isolation toolkit. Our tookit will build on the WebAssembly
compiler to isolate libraries in Firefox. But, as part of this toolkit we will
also develop and apply a library for safely interfacing with sandboxed libraries (and
sanitizing data coming from them). with this toolkit we can ensure that any
vulnerability in third-party libraries (e.g., libogg or libpng) cannot be used
to be used to compromise Firefox.
| C/C++, experience with WebAssembly
| [https://mozillians.org/en-US/u/erahm/ Eric Rahm]
| [https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|
|-
| Test automation our linting tools
| We have a several linting tools running on Firefox code base, they currently don't have a test suite.
The goal of this project is to make sure that tests are executed. We currently have a similar [https://bugzilla.mozilla.org/show_bug.cgi?id=1432410 test automation for static analyzer jobs]. The idea would be to extend (or replicate) this model for [https://searchfox.org/mozilla-central/source/tools/lint/ ./mach lint] (which run flake8, eslint, etc) and [https://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/mach_commands.py#2327 ./mach clang-format]
The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1448008
| Python
| [https://github.com/sylvestre Sylvestre] (s@mozilla.com)
| [https://github.com/abpostelnicu Andi Postelnicu] (andi@mozilla.com)
|
|-
| Firefox Account Security Dashboard
| Firefox Account administrators and users need an easily digestible view into the important events that have occurred on an account, providing a way to audit for irregularities.
| JavaScript, HTML, CSS, MySQL
| [https://mozillians.org/u/vbudhram/ Vijay Budhram], [https://mozillians.org/u/stomlinson/ Shane Tomlinson]
| [https://mozillians.org/u/vbudhram/ Vijay Budhram], [https://mozillians.org/u/stomlinson/ Shane Tomlinson]
| The Firefox Account platform tracks security information about an account, but does not surface this information in an easily consumable format. Users and administrators should be able to see a timeline of an account’s security related events, such as connecting devices, signing into services, changing or resetting passwords, and adding or removing 2FA. Each event in the timeline should include a timestamp, IP address, and location information when they occurred.

This project would entail updating our security event API to ensure we track and expose the required data. The first phase is to build a script that consumes the API and pretty prints the timeline. The second phase is to provide a web interface for the security timeline.

|-
| Improving FastParquet
| FastParquet is a Python library that needs improvement to how it writes the parquet file format
| Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/klahnakoski/mo-parquet/blob/dev/docs/StudentProject%202019.md Read more]

|-
| Faster Pyparsing
| Pyparsing is a Python library that provides a DSL for language specification. It could use some optimization.
| Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/moz-sql-parser/blob/dev/docs/Student%20Project%202019.md Read more]

|-
| Regression Detection
| Use machine learning to guide statistical model selection, then use the model(s) to detect regressions in future data.
| Machine Learning, Statistics, Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/ActiveData/blob/dev/docs/Student%20Project%20190121.md Read more]

|-
| Bugzilla Kanban Board
| Show bugs like [https://en.wikipedia.org/wiki/Post-it_Note post-it notes] on a [https://en.wikipedia.org/wiki/Whiteboard whiteboard]. Much like a [https://en.wikipedia.org/wiki/Kanban_board Kanban board]
| JSX/React
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/bugzilla-tiles Read more]

|-
| More ActiveData Recipes
| Build out the user interface of the [https://github.com/mozilla/active-data-recipes active-data-recipes] project so that making new recipes is even easier
| JSX/React some Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ahal/ Andrew Halberstadt]
| [https://github.com/mozilla/active-data-recipes/pull/112/files#diff-0f126940e57c54541662345b499622f1 PR with proposal] or [https://github.com/mozilla/active-data-recipes/tree/master/docs/Student%20Project%20190130.md Read more]

|-
| ..your next idea here!
| some details
| skills/language
| reporter
| mentor
| comments

Community:SummerOfCode19:Brainstorming

2019-02-03T15:42:10Z

Klahnakoski: add project

Once again, Mozilla intends to apply to participate in Google's Summer Of Code.

Mozilla community members, please submit proposals here for 2019 Google Summer of Code projects with Mozilla. This page is for brainstorming - as we approach the deadline, those ideas that are accepted will be transferred to the [[Community:SummerOfCode19|official list]].)

Our application for summer of 2019 goes into Google on '''February 4th''', so get those project ideas in well ahead of time.

Are you a student looking to apply to GSoC with Mozilla? Your first stop should be the [[Community:SummerOfCode19|official list of ideas]]. This page is full of weird ideas, only some of which will make the cut. It could be that they are not properly defined, the wrong size, or don't have a mentor. That makes them less likely to get accepted. You can, of course, also submit your own ideas - you don't have to put an idea on this page and get it 'made official' in order to send in a proposal for it.

==How To Write A Good Project Proposal==

Before adding an proposal to this list, please consider the following:

* '''Be specific'''. It's hard to understand the impact of, or the size of, vague proposals.
* '''Consider size'''. The student has eight weeks to design, code, test and document the proposal. It needs to fill, but not overfill, that time.
* '''Do your research'''. Support the idea with well-researched links.
* '''Don't morph other people's ideas'''. If you have a related idea, place it next to the existing one, or add a comment.
* '''Insert only your own name into the Mentor column''', and then only if you are willing to take on the responsibility. If you think the SoC admins won't know who you are, leave contact details.
* '''Check back regularly'''. The administrators may have questions about your idea that you will need to answer.
* '''Know when to give up'''. If you've added the same idea for the last three years and it hasn't made it to the official page, perhaps you can predict what will happen this time.

==Suggestion List==

[[SummerOfCode|Here are the ideas lists from previous years]].

Proposals can be in almost any part of the Mozilla project, though they do need to be mostly focused on code.

Here are the proposals. Feel free to add a new one.

== 2019 Proposed Project List ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Additional Comments
|-
| Improve Python in the browser
| The [https://github.com/iodide-project/pyodide pyodide] project allows the Python scientific stack to run in the browser by compiling it to WebAssembly. Help make stuff run better and faster there.
| Python and JavaScript. Can learn the WebAssembly parts as you go.
| [https://mozillians.org/en-US/u/mdboom/ Michael Droettboom]
| [https://mozillians.org/en-US/u/mdboom/ Michael Droettboom]
| There are a number of specific projects we have in mind, but are open to other proposals that are within scope and seem practical within the timeframe. (1) Implement matplotlib's display on top of Web APIs (HTML5 Canvas, etc.) This would allow us to avoid shipping a whole separate rendering engine to the browser. (2) Build WebAssembly support into the conda packaging system to make it easier to distribute new compiled packages for Pyodide. (3) Make multi-dimensional arrays sharable between Python and Javascript. See Pyodide's [https://github.com/iodide-project/pyodide/issues list of issues] for additional ideas. About the mentor: Michael Droettboom is a Staff Data Engineer at Mozilla, and a former lead developer of matplotlib with years of experience building the Python scientific ecosystem.
|-
| ReSpec
| [https://github.com/w3c/respec/ ReSpec] is a JS-based tool used to write W3C Specifications (Web Standards) that is widely used by the Web Standards Community. With 6+ years of development, it's heavily depended upon by the W3C community at large (of which Mozilla is an active participant). ReSpec's code is in need of some modernization, optimizations, and bug fixes - and we could use your help! In this project, you would have the opportunity to make ReSpec's UI more accessible, making it leaner and faster using distributed processing with Web Workers, and/or adding new features to make the lives of W3C spec Editor's better.
| JavaScript, HTML, CSS.
| [https://mozillians.org/en-US/u/mcaceres/ Marcos Caceres]
| [https://mozillians.org/en-US/u/mcaceres/ Marcos Caceres]
| ReSpec offers students the opportunity to work on a large code base that has extensive real world use and impact. The project offers students an extensive range of problems to tackle, from UI design, to concurrent processing (using Web Workers to do distributed text processing), dealing with accessibility and internationalization, writing and learning about unit and integration tests, security, code review, etc. - as well as exposure to the W3C and the web standards community, this project also aims at teaching students about how web standards are put together. To determine if this is a project you would like to be part of, see the [https://github.com/w3c/respec/issues/ list of issues] you could work on. It's a great opportunity to learn about all aspects of open source software development, but with the freedom to take on small to large challenges over the Summer (depending on your skill level and level of confidence). About the mentor: Marcos Caceres is a Staff Engineer at Mozilla who has been working on Web Standards for over a decade. Marcos is the lead maintainer of ReSpec. Marcos has extensive experience mentoring developers and has previously successfully mentor a GSO student.
|-
| Ship Public Suffix List (PSL) over Remote Settings
| The list of public domain suffixes (DNS) is shipped with every release, with no way to update it on long term releases for example.
Now that Remote Settings has become a solid solution to ship data, we could use it to publish updates of the PSL.
The task consist in migrating the current client code to read from Remote Settings instead of a file, and implement a scheduled job (like Python) to push updates automatically (most likely compiled as a DAFSA file)
| JavaScript and some Python basics
| [https://mozillians.org/en-US/u/leplatrem/ Mathieu Leplatre]
| [https://mozillians.org/en-US/u/leplatrem/ Mathieu Leplatre]
| https://bugzilla.mozilla.org/show_bug.cgi?id=1083971
|-
| [https://github.com/marco-c/bugbug bugbug]
| A platform for machine learning projects applied on Bugzilla, VCS and other software development data.
| Python
| [https://github.com/marco-c Marco Castelluccio] (FIRST_NAME@mozilla.com)
| [https://github.com/marco-c Marco Castelluccio] (FIRST_NAME@mozilla.com)
| The project will involve one or more of:
i) building additional classifiers (e.g., to detect bugs with no steps to reproduce, or to suggest a developer to assign to a bug, and so on);

ii) improving accuracy/precision/recall of the existing classifiers by implementing other machine learning techniques (e.g., by using convolutional neural networks or recurrent neural networks);

iii) improving accuracy/precision/recall by implementing additional feature extraction steps or making the already existing ones better.
|-
| Make the Firefox WebAuthn Soft Token a Real Thing
| The Web Authentication Soft Token provides second-factor login support without needing a Security Key dongle. It would be very usable if the Soft Token were a) synchronized across an account using Sync, b) could be controlled via a Web Extension, and perhaps c) had some UI. If these things were true, most people could get quality authentication support without buying another device.
| C++, Javascript, Basic cryptography
| [https://mozillians.org/en-US/u/jcjones/ J.C. Jones]
| [https://mozillians.org/en-US/u/jcjones/ J.C. Jones]
| https://wiki.mozilla.org/Security/CryptoEngineering#Web_Authentication
|-
| WebSocket Monitor
| Support for WebSocket monitoring and inspection in Firefox DevTools.
| JavaScript/React
| [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko]
| [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko]
| This project aims at providing support for WebSocket monitoring and inspection in Firefox DevTools. The feature should be built on top of the existing Network panel UI and responsible for visualizing data sent through WebSocket connection (i.e. WS frames). The user should be able to use the UI to see as well as analyse the data (search, filter, etc.).
* [https://docs.google.com/document/d/1ruHk-BA3cqzU7VHoVltnAwWt_2OXKOOAI4nTHwYllzk/edit# Detailed Project Description]
|-
| Helpful crash reporter
| The crash reporter only allows users to send crash reports but in some cases it might help the user diagnose the crash and solve it on his/her own
| C++, Javascript
| [https://mozillians.org/en-US/u/gsvelto/ Gabriele Svelto]
| [https://mozillians.org/en-US/u/gsvelto/ Gabriele Svelto]
| There's a few things that could be implemented:
* A quick test of the memory owned by the crashed process (such as those in [http://www.memtest.org/ memtest86+]) might catch faulty memory, a common cause for crashes
* The crash reporter client might try and validate Firefox files which can sometimes become corrupted (usually because of hardware issues). If they are it can prompt the user to re-install Firefox
* Many crashes are caused by buggy graphics drivers, while we blacklist the most egregious offenders we can't cover them all. The crash reporter might identify a faulty driver (if a bug for it has already been filed) and point the user to up-to-date drivers
* For crashes caused by known bugs it should be possible to point the user to the bug filed on bugzilla
|-
| Debugger Inline Variable Preview
| When the Firefox DevTools debugger is paused, users can hover over variables to get a useful tooltip that details the variable's value at that time. While this popup is very informative, one valuable enhancement would be displaying relevant contextual variables values alongside the variable inline, alleviating the need for tooltips and allowing the user to more quickly get the information they need. The applicant will work alongside the Debugger's team to implement this feature based on UX mockups and be given space to share and implement ideas of their own.
| Javascript
| [https://mozillians.org/en-US/u/davidwalsh/ David Walsh]
| [https://mozillians.org/en-US/u/davidwalsh/ David Walsh]
|
|-
| GitHub Checks Support Improvements
| [https://github.com/taskcluster/taskcluster Taskcluster] currently supports reporting results to the [https://github.com/taskcluster/taskcluster/pull/129/checks?check_run_id=54327344 GitHub Checks API], but only reports success or failure. Let's add support for showing [https://developer.github.com/v3/checks/runs/ annotations] - snippets of log output, more detailed results, images, and so on. We can even add support for additional "actions" on the task, such as re-running with debugging enabled.
| Server-side JS
| [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
| [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko], [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
|
|-
| Support GitHub Logins in Taskcluster
| [https://github.com/taskcluster/taskcluster Taskcluster] currently supports logging in with Auth0, the Mozilla login system. We would like to make it useful outside of Mozilla, and most other users do their development on GitHub, making GitHub logins a good solution. This project would involve adding support for signing in with GitHub, as well as the more challenging task of assigning appropriate permissions to users based on the setup of their GitHub account.
| Server-side JS
| [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
| [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko], [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
|
|-
| Improve Webdriver support in Servo
| [https://github.com/servo/servo/ Servo] currently supports a minimal subset of the [https://w3c.github.io/webdriver/ Webdriver standard]. We would like to improve Servo's support, and verify its correctness by passing a [https://github.com/web-platform-tests/wpt/tree/master/webdriver set of automated tests]. This project would involve writing Rust code to extend the webdriver server inside of Servo, as well as JavaScript and Python to support the [https://web-platform-tests.org/writing-tests/testdriver.html testdriver.js] testharness.
| Familiarity with Python & JavaScript; interest in learning Rust
| [https://mozillians.org/en-US/u/jdm/ Josh Bowman-Matthews]
| [https://mozillians.org/en-US/u/jdm/ Josh Bowman-Matthews]
| [https://github.com/servo/servo/wiki/Support-Webdriver-based-tests-project Project description]
|-
| Support importing Instruments profiles in perf.html
| [https://github.com/devtools-html/perf.html/ perf.html] visualizes performance data recorded from various performance analysis tools. It is a tool designed to consume performance profiles from Gecko Profiler but can visualize any profiler able to output JSON. It currently supports Gecko, Chrome and perf profile formats. Instruments is a performance analyzer that comes with Xcode. This project would involve adding support for Instruments profile import in perf.html.
| Familiarity with JavaScript & React
| [https://mozillians.org/en-US/u/canaltinova/ Nazım Can Altınova]
| [https://mozillians.org/en-US/u/canaltinova/ Nazım Can Altınova]
| https://github.com/devtools-html/perf.html/issues/1138
|-
| Common Voice - WebAssembly MP3 Encoding
| Currently Common Voice doesn’t support Safari, which is also why we have an iOS app. The only reason being the missing MediaRecorder API. It could be polyfilled (rebuilt in “userspace”) by compiling an MP3 encoder to WebAssembly. I’ve tried that a couple of times, but never had enough time to fix the opaque bugs happening in Safari. This could also be turned into its own library and would be a nice story overall of how WASM can help with WebCompat and missing APIs.
| JavaScript
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://github.com/mozilla/voice-web/issues/469 This GitHub issue] lines out some thoughts around how to implement it and you can find references to closed PRs which tried implementing it in various ways.
|-
| Common Voice - Voice Wave Avatar
| We’d like our users to have unique(ish) avatars based either on the characteristics of their voice or a visualization of how their name (or an utterance of their choosing) is pronounced. It could also be a combination of the two ideas. We’re very open to explore this space together, though the a candidate should have some knowledge in sound theory.
| JavaScript, Some knowledge of sound theory
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://mozillians.org/u/gweber/ Gregor Weber]
|-
| Tab Manager menu in Firefox
| This project will extend the tab overflow menu - which shows tabs not visible in the browser's tab strip - to allow management of all open tabs across all browser windows. The selected student will be working directly in the Firefox codebase to add functionality and new menu structures to make this easily accessible for end users.
| JavaScript, CSS, and web experience
| [https://mozillians.org/en-US/u/sfoster/ Sam Foster], [https://mozillians.org/en-US/u/bbell/ Bryan Bell]
| [https://mozillians.org/en-US/u/sfoster/ Sam Foster]
| We have [https://mozilla.invisionapp.com/share/4SNCEPDUEZ6#/screens UX mockups] for this feature, which could be broken into two phases. We also have a [https://bugzilla.mozilla.org/show_bug.cgi?id=1480542 bug on file], where discussion has begun. While working on this you will become very familiar with the Browser Toolbox, our own "Inspector" tool for the browser user-interface, as well as writing automated tests for the new feature you're adding. The existing tab overflow code lives in our [https://searchfox.org/mozilla-central/source/browser/base/content/browser-allTabsMenu.js browser-allTabsMenu.js] file, which will be the starting point for the new tab manager. You can look at this and the existing tab code to get an idea of how this currently works.
-
|-
|-
| Firefox Reader Redesign
| The design of Firefox’s Reader Mode has languished behind as Quantum has implemented the new Photon Design System. The interface needs to be rebuilt using new visual and interaction styles to match the Photon Design System.
| JavaScript, CSS, and web experience
| [https://mozillians.org/en-US/u/awallin/ Abraham Wallin]
| [https://mozillians.org/en-US/u/eeejay/ Eitan Isaacson]
| [https://mozilla.invisionapp.com/share/87N9YQYCTJZ#/315073983_Reader_View_Redesign UX Mockups] for this feature are available with visual bugs have been reported [https://bugzilla.mozilla.org/show_bug.cgi?id=1187696 here] and [https://github.com/devtools-html/ux/issues/5 here]. Functional bugs and feature enhancements have been documented [https://github.com/mozilla/readability/issues?q=is%3Aissue+is%3Aopen+label%3Areader-mode-has-issues here], [https://github.com/mozilla/readability/issues?q=is%3Aissue+is%3Aopen+label%3Ashould-be-readerable here], [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=comp%3Areader%20prod%3DToolkit%20whiteboard%3Areadability-algorithm&list_id=14539703 here], and [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=comp%3Areader%20prod%3DToolkit%20whiteboard%3Aisreadable&list_id=14539704 finally here]. The request is for an engineering student to implement the designs and tackle the queue of bugs/enhancements within the Firefox code base. Mentors will support with prioritization, design direction/assets, and technical guidance.

|-
| An Android file downloader designed for Emerging Markets
| A lesson learned thanks to our UX team is in Emerging Markets the data plan is dynamic: in late nights we have the most affordable bandwidth. Here's the question: Why not schedule big files and videos and have them downloaded when you're sleeping? The mvp would be an App which we can send urls to. After receiving these urls the App either downloads it directly or defer it to late night. As there are more and more background restrictions enforced on new Android APIs, this should be a fun and challenging journey.

A stretch goal would be to embed this downloader in our browser for Emerging Markets, Firefox Lite. Firefox Lite is not satisfied with the current Android Download Manager in several ways: We'd like to give users the ability to pause/resume a download, we'd like to download a file directly to SDcard (opposed to download it to the main storage and move it into SDcard).

We've also prepared an even more ambitious mission for those who want tough challenges: Design the app and make it dynamic deliverable. With aabs we can satisfy both light and heavy users by defaulting Android Download Manager as the download tool and prepare the aforementioned downloader dynamically so that Firefox Lite itself is still minimized in terms of disk size. Nevin and mTwTm are Android developers who can provide assistance to Android App design.
| Android Java/Kotlin
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)]
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)] (mTwTm@mozilla.com), [https://github.com/cnevinc/ Nevin Chen] (nevin@mozilla.com)
|
|-
| Toolkit for sandboxing third-parties libraries in Firefox
| Firefox supports a long tail of infrequently used image and audio formats to
support the occasional website that uses them. Each such format requires the
Firefox decoder to use a new open source library for parsing and decoding.
This, unfortunately, increases the attack surface of Firefox and as we saw in
Pwn2Own 2018, Firefox was successfully exploited via a bugs in such libraries
(libogg in this case).

This project proposes to sandbox third-party libraries in Firefox by building a
new software-fault isolation toolkit. Our tookit will build on the WebAssembly
compiler to isolate libraries in Firefox. But, as part of this toolkit we will
also develop and apply a library for safely interfacing with sandboxed libraries (and
sanitizing data coming from them). with this toolkit we can ensure that any
vulnerability in third-party libraries (e.g., libogg or libpng) cannot be used
to be used to compromise Firefox.
| C/C++, experience with WebAssembly
| [https://mozillians.org/en-US/u/erahm/ Eric Rahm]
| [https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|
|-
| Test automation our linting tools
| We have a several linting tools running on Firefox code base, they currently don't have a test suite.
The goal of this project is to make sure that tests are executed. We currently have a similar [https://bugzilla.mozilla.org/show_bug.cgi?id=1432410 test automation for static analyzer jobs]. The idea would be to extend (or replicate) this model for [https://searchfox.org/mozilla-central/source/tools/lint/ ./mach lint] (which run flake8, eslint, etc) and [https://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/mach_commands.py#2327 ./mach clang-format]
The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1448008
| Python
| [https://github.com/sylvestre Sylvestre] (s@mozilla.com)
| [https://github.com/abpostelnicu Andi Postelnicu] (andi@mozilla.com)
|
|-
| Firefox Account Security Dashboard
| Firefox Account administrators and users need an easily digestible view into the important events that have occurred on an account, providing a way to audit for irregularities.
| JavaScript, HTML, CSS, MySQL
| [https://mozillians.org/u/vbudhram/ Vijay Budhram], [https://mozillians.org/u/stomlinson/ Shane Tomlinson]
| [https://mozillians.org/u/vbudhram/ Vijay Budhram], [https://mozillians.org/u/stomlinson/ Shane Tomlinson]
| The Firefox Account platform tracks security information about an account, but does not surface this information in an easily consumable format. Users and administrators should be able to see a timeline of an account’s security related events, such as connecting devices, signing into services, changing or resetting passwords, and adding or removing 2FA. Each event in the timeline should include a timestamp, IP address, and location information when they occurred.

This project would entail updating our security event API to ensure we track and expose the required data. The first phase is to build a script that consumes the API and pretty prints the timeline. The second phase is to provide a web interface for the security timeline.

|-
| Improving FastParquet
| FastParquet is a Python library that needs improvement to how it writes the parquet file format
| Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/klahnakoski/mo-parquet/blob/dev/docs/StudentProject%202019.md Read more]

|-
| Faster Pyparsing
| Pyparsing is a Python library that provides a DSL for language specification. It could use some optimization.
| Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/moz-sql-parser/blob/dev/docs/Student%20Project%202019.md Read more]

|-
| Regression Detection
| Use machine learning to guide statistical model selection, then use the model(s) to detect regressions in future data.
| Machine Learning, Statistics, Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/ActiveData/blob/dev/docs/Student%20Project%20190121.md Read more]

|-
| Bugzilla Kanban Board
| Show bugs like [https://en.wikipedia.org/wiki/Post-it_Note post-it notes] on a [https://en.wikipedia.org/wiki/Whiteboard whiteboard]. Much like a [https://en.wikipedia.org/wiki/Kanban_board Kanban board]
| JSX/React
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/bugzilla-tiles Read more]

|-
| ..your next idea here!
| some details
| skills/language
| reporter
| mentor
| comments

Community:SummerOfCode19:Brainstorming

2019-02-03T15:07:07Z

Klahnakoski: Add more projects

Once again, Mozilla intends to apply to participate in Google's Summer Of Code.

Mozilla community members, please submit proposals here for 2019 Google Summer of Code projects with Mozilla. This page is for brainstorming - as we approach the deadline, those ideas that are accepted will be transferred to the [[Community:SummerOfCode19|official list]].)

Our application for summer of 2019 goes into Google on '''February 4th''', so get those project ideas in well ahead of time.

Are you a student looking to apply to GSoC with Mozilla? Your first stop should be the [[Community:SummerOfCode19|official list of ideas]]. This page is full of weird ideas, only some of which will make the cut. It could be that they are not properly defined, the wrong size, or don't have a mentor. That makes them less likely to get accepted. You can, of course, also submit your own ideas - you don't have to put an idea on this page and get it 'made official' in order to send in a proposal for it.

==How To Write A Good Project Proposal==

Before adding an proposal to this list, please consider the following:

* '''Be specific'''. It's hard to understand the impact of, or the size of, vague proposals.
* '''Consider size'''. The student has eight weeks to design, code, test and document the proposal. It needs to fill, but not overfill, that time.
* '''Do your research'''. Support the idea with well-researched links.
* '''Don't morph other people's ideas'''. If you have a related idea, place it next to the existing one, or add a comment.
* '''Insert only your own name into the Mentor column''', and then only if you are willing to take on the responsibility. If you think the SoC admins won't know who you are, leave contact details.
* '''Check back regularly'''. The administrators may have questions about your idea that you will need to answer.
* '''Know when to give up'''. If you've added the same idea for the last three years and it hasn't made it to the official page, perhaps you can predict what will happen this time.

==Suggestion List==

[[SummerOfCode|Here are the ideas lists from previous years]].

Proposals can be in almost any part of the Mozilla project, though they do need to be mostly focused on code.

Here are the proposals. Feel free to add a new one.

== 2019 Proposed Project List ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Additional Comments
|-
| Improve Python in the browser
| The [https://github.com/iodide-project/pyodide pyodide] project allows the Python scientific stack to run in the browser by compiling it to WebAssembly. Help make stuff run better and faster there.
| Python and JavaScript. Can learn the WebAssembly parts as you go.
| [https://mozillians.org/en-US/u/mdboom/ Michael Droettboom]
| [https://mozillians.org/en-US/u/mdboom/ Michael Droettboom]
| There are a number of specific projects we have in mind, but are open to other proposals that are within scope and seem practical within the timeframe. (1) Implement matplotlib's display on top of Web APIs (HTML5 Canvas, etc.) This would allow us to avoid shipping a whole separate rendering engine to the browser. (2) Build WebAssembly support into the conda packaging system to make it easier to distribute new compiled packages for Pyodide. (3) Make multi-dimensional arrays sharable between Python and Javascript. See Pyodide's [https://github.com/iodide-project/pyodide/issues list of issues] for additional ideas. About the mentor: Michael Droettboom is a Staff Data Engineer at Mozilla, and a former lead developer of matplotlib with years of experience building the Python scientific ecosystem.
|-
| ReSpec
| [https://github.com/w3c/respec/ ReSpec] is a JS-based tool used to write W3C Specifications (Web Standards) that is widely used by the Web Standards Community. With 6+ years of development, it's heavily depended upon by the W3C community at large (of which Mozilla is an active participant). ReSpec's code is in need of some modernization, optimizations, and bug fixes - and we could use your help! In this project, you would have the opportunity to make ReSpec's UI more accessible, making it leaner and faster using distributed processing with Web Workers, and/or adding new features to make the lives of W3C spec Editor's better.
| JavaScript, HTML, CSS.
| [https://mozillians.org/en-US/u/mcaceres/ Marcos Caceres]
| [https://mozillians.org/en-US/u/mcaceres/ Marcos Caceres]
| ReSpec offers students the opportunity to work on a large code base that has extensive real world use and impact. The project offers students an extensive range of problems to tackle, from UI design, to concurrent processing (using Web Workers to do distributed text processing), dealing with accessibility and internationalization, writing and learning about unit and integration tests, security, code review, etc. - as well as exposure to the W3C and the web standards community, this project also aims at teaching students about how web standards are put together. To determine if this is a project you would like to be part of, see the [https://github.com/w3c/respec/issues/ list of issues] you could work on. It's a great opportunity to learn about all aspects of open source software development, but with the freedom to take on small to large challenges over the Summer (depending on your skill level and level of confidence). About the mentor: Marcos Caceres is a Staff Engineer at Mozilla who has been working on Web Standards for over a decade. Marcos is the lead maintainer of ReSpec. Marcos has extensive experience mentoring developers and has previously successfully mentor a GSO student.
|-
| Ship Public Suffix List (PSL) over Remote Settings
| The list of public domain suffixes (DNS) is shipped with every release, with no way to update it on long term releases for example.
Now that Remote Settings has become a solid solution to ship data, we could use it to publish updates of the PSL.
The task consist in migrating the current client code to read from Remote Settings instead of a file, and implement a scheduled job (like Python) to push updates automatically (most likely compiled as a DAFSA file)
| JavaScript and some Python basics
| [https://mozillians.org/en-US/u/leplatrem/ Mathieu Leplatre]
| [https://mozillians.org/en-US/u/leplatrem/ Mathieu Leplatre]
| https://bugzilla.mozilla.org/show_bug.cgi?id=1083971
|-
| [https://github.com/marco-c/bugbug bugbug]
| A platform for machine learning projects applied on Bugzilla, VCS and other software development data.
| Python
| [https://github.com/marco-c Marco Castelluccio] (FIRST_NAME@mozilla.com)
| [https://github.com/marco-c Marco Castelluccio] (FIRST_NAME@mozilla.com)
| The project will involve one or more of:
i) building additional classifiers (e.g., to detect bugs with no steps to reproduce, or to suggest a developer to assign to a bug, and so on);

ii) improving accuracy/precision/recall of the existing classifiers by implementing other machine learning techniques (e.g., by using convolutional neural networks or recurrent neural networks);

iii) improving accuracy/precision/recall by implementing additional feature extraction steps or making the already existing ones better.
|-
| Make the Firefox WebAuthn Soft Token a Real Thing
| The Web Authentication Soft Token provides second-factor login support without needing a Security Key dongle. It would be very usable if the Soft Token were a) synchronized across an account using Sync, b) could be controlled via a Web Extension, and perhaps c) had some UI. If these things were true, most people could get quality authentication support without buying another device.
| C++, Javascript, Basic cryptography
| [https://mozillians.org/en-US/u/jcjones/ J.C. Jones]
| [https://mozillians.org/en-US/u/jcjones/ J.C. Jones]
| https://wiki.mozilla.org/Security/CryptoEngineering#Web_Authentication
|-
| WebSocket Monitor
| Support for WebSocket monitoring and inspection in Firefox DevTools.
| JavaScript/React
| [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko]
| [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko]
| This project aims at providing support for WebSocket monitoring and inspection in Firefox DevTools. The feature should be built on top of the existing Network panel UI and responsible for visualizing data sent through WebSocket connection (i.e. WS frames). The user should be able to use the UI to see as well as analyse the data (search, filter, etc.).
* [https://docs.google.com/document/d/1ruHk-BA3cqzU7VHoVltnAwWt_2OXKOOAI4nTHwYllzk/edit# Detailed Project Description]
|-
| Helpful crash reporter
| The crash reporter only allows users to send crash reports but in some cases it might help the user diagnose the crash and solve it on his/her own
| C++, Javascript
| [https://mozillians.org/en-US/u/gsvelto/ Gabriele Svelto]
| [https://mozillians.org/en-US/u/gsvelto/ Gabriele Svelto]
| There's a few things that could be implemented:
* A quick test of the memory owned by the crashed process (such as those in [http://www.memtest.org/ memtest86+]) might catch faulty memory, a common cause for crashes
* The crash reporter client might try and validate Firefox files which can sometimes become corrupted (usually because of hardware issues). If they are it can prompt the user to re-install Firefox
* Many crashes are caused by buggy graphics drivers, while we blacklist the most egregious offenders we can't cover them all. The crash reporter might identify a faulty driver (if a bug for it has already been filed) and point the user to up-to-date drivers
* For crashes caused by known bugs it should be possible to point the user to the bug filed on bugzilla
|-
| Debugger Inline Variable Preview
| When the Firefox DevTools debugger is paused, users can hover over variables to get a useful tooltip that details the variable's value at that time. While this popup is very informative, one valuable enhancement would be displaying relevant contextual variables values alongside the variable inline, alleviating the need for tooltips and allowing the user to more quickly get the information they need. The applicant will work alongside the Debugger's team to implement this feature based on UX mockups and be given space to share and implement ideas of their own.
| Javascript
| [https://mozillians.org/en-US/u/davidwalsh/ David Walsh]
| [https://mozillians.org/en-US/u/davidwalsh/ David Walsh]
|
|-
| GitHub Checks Support Improvements
| [https://github.com/taskcluster/taskcluster Taskcluster] currently supports reporting results to the [https://github.com/taskcluster/taskcluster/pull/129/checks?check_run_id=54327344 GitHub Checks API], but only reports success or failure. Let's add support for showing [https://developer.github.com/v3/checks/runs/ annotations] - snippets of log output, more detailed results, images, and so on. We can even add support for additional "actions" on the task, such as re-running with debugging enabled.
| Server-side JS
| [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
| [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko], [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
|
|-
| Support GitHub Logins in Taskcluster
| [https://github.com/taskcluster/taskcluster Taskcluster] currently supports logging in with Auth0, the Mozilla login system. We would like to make it useful outside of Mozilla, and most other users do their development on GitHub, making GitHub logins a good solution. This project would involve adding support for signing in with GitHub, as well as the more challenging task of assigning appropriate permissions to users based on the setup of their GitHub account.
| Server-side JS
| [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
| [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko], [https://mozillians.org/en-US/u/djmitche/ Dustin Mitchell]
|
|-
| Improve Webdriver support in Servo
| [https://github.com/servo/servo/ Servo] currently supports a minimal subset of the [https://w3c.github.io/webdriver/ Webdriver standard]. We would like to improve Servo's support, and verify its correctness by passing a [https://github.com/web-platform-tests/wpt/tree/master/webdriver set of automated tests]. This project would involve writing Rust code to extend the webdriver server inside of Servo, as well as JavaScript and Python to support the [https://web-platform-tests.org/writing-tests/testdriver.html testdriver.js] testharness.
| Familiarity with Python & JavaScript; interest in learning Rust
| [https://mozillians.org/en-US/u/jdm/ Josh Bowman-Matthews]
| [https://mozillians.org/en-US/u/jdm/ Josh Bowman-Matthews]
| [https://github.com/servo/servo/wiki/Support-Webdriver-based-tests-project Project description]
|-
| Support importing Instruments profiles in perf.html
| [https://github.com/devtools-html/perf.html/ perf.html] visualizes performance data recorded from various performance analysis tools. It is a tool designed to consume performance profiles from Gecko Profiler but can visualize any profiler able to output JSON. It currently supports Gecko, Chrome and perf profile formats. Instruments is a performance analyzer that comes with Xcode. This project would involve adding support for Instruments profile import in perf.html.
| Familiarity with JavaScript & React
| [https://mozillians.org/en-US/u/canaltinova/ Nazım Can Altınova]
| [https://mozillians.org/en-US/u/canaltinova/ Nazım Can Altınova]
| https://github.com/devtools-html/perf.html/issues/1138
|-
| Common Voice - WebAssembly MP3 Encoding
| Currently Common Voice doesn’t support Safari, which is also why we have an iOS app. The only reason being the missing MediaRecorder API. It could be polyfilled (rebuilt in “userspace”) by compiling an MP3 encoder to WebAssembly. I’ve tried that a couple of times, but never had enough time to fix the opaque bugs happening in Safari. This could also be turned into its own library and would be a nice story overall of how WASM can help with WebCompat and missing APIs.
| JavaScript
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://github.com/mozilla/voice-web/issues/469 This GitHub issue] lines out some thoughts around how to implement it and you can find references to closed PRs which tried implementing it in various ways.
|-
| Common Voice - Voice Wave Avatar
| We’d like our users to have unique(ish) avatars based either on the characteristics of their voice or a visualization of how their name (or an utterance of their choosing) is pronounced. It could also be a combination of the two ideas. We’re very open to explore this space together, though the a candidate should have some knowledge in sound theory.
| JavaScript, Some knowledge of sound theory
| [https://mozillians.org/u/gweber/ Gregor Weber]
| [https://mozillians.org/u/gweber/ Gregor Weber]
|-
| Tab Manager menu in Firefox
| This project will extend the tab overflow menu - which shows tabs not visible in the browser's tab strip - to allow management of all open tabs across all browser windows. The selected student will be working directly in the Firefox codebase to add functionality and new menu structures to make this easily accessible for end users.
| JavaScript, CSS, and web experience
| [https://mozillians.org/en-US/u/sfoster/ Sam Foster], [https://mozillians.org/en-US/u/bbell/ Bryan Bell]
| [https://mozillians.org/en-US/u/sfoster/ Sam Foster]
| We have [https://mozilla.invisionapp.com/share/4SNCEPDUEZ6#/screens UX mockups] for this feature, which could be broken into two phases. We also have a [https://bugzilla.mozilla.org/show_bug.cgi?id=1480542 bug on file], where discussion has begun. While working on this you will become very familiar with the Browser Toolbox, our own "Inspector" tool for the browser user-interface, as well as writing automated tests for the new feature you're adding. The existing tab overflow code lives in our [https://searchfox.org/mozilla-central/source/browser/base/content/browser-allTabsMenu.js browser-allTabsMenu.js] file, which will be the starting point for the new tab manager. You can look at this and the existing tab code to get an idea of how this currently works.
-
|-
|-
| Firefox Reader Redesign
| The design of Firefox’s Reader Mode has languished behind as Quantum has implemented the new Photon Design System. The interface needs to be rebuilt using new visual and interaction styles to match the Photon Design System.
| JavaScript, CSS, and web experience
| [https://mozillians.org/en-US/u/awallin/ Abraham Wallin]
| [https://mozillians.org/en-US/u/eeejay/ Eitan Isaacson]
| [https://mozilla.invisionapp.com/share/87N9YQYCTJZ#/315073983_Reader_View_Redesign UX Mockups] for this feature are available with visual bugs have been reported [https://bugzilla.mozilla.org/show_bug.cgi?id=1187696 here] and [https://github.com/devtools-html/ux/issues/5 here]. Functional bugs and feature enhancements have been documented [https://github.com/mozilla/readability/issues?q=is%3Aissue+is%3Aopen+label%3Areader-mode-has-issues here], [https://github.com/mozilla/readability/issues?q=is%3Aissue+is%3Aopen+label%3Ashould-be-readerable here], [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=comp%3Areader%20prod%3DToolkit%20whiteboard%3Areadability-algorithm&list_id=14539703 here], and [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=comp%3Areader%20prod%3DToolkit%20whiteboard%3Aisreadable&list_id=14539704 finally here]. The request is for an engineering student to implement the designs and tackle the queue of bugs/enhancements within the Firefox code base. Mentors will support with prioritization, design direction/assets, and technical guidance.

|-
| An Android file downloader designed for Emerging Markets
| A lesson learned thanks to our UX team is in Emerging Markets the data plan is dynamic: in late nights we have the most affordable bandwidth. Here's the question: Why not schedule big files and videos and have them downloaded when you're sleeping? The mvp would be an App which we can send urls to. After receiving these urls the App either downloads it directly or defer it to late night. As there are more and more background restrictions enforced on new Android APIs, this should be a fun and challenging journey.

A stretch goal would be to embed this downloader in our browser for Emerging Markets, Firefox Lite. Firefox Lite is not satisfied with the current Android Download Manager in several ways: We'd like to give users the ability to pause/resume a download, we'd like to download a file directly to SDcard (opposed to download it to the main storage and move it into SDcard).

We've also prepared an even more ambitious mission for those who want tough challenges: Design the app and make it dynamic deliverable. With aabs we can satisfy both light and heavy users by defaulting Android Download Manager as the download tool and prepare the aforementioned downloader dynamically so that Firefox Lite itself is still minimized in terms of disk size. Nevin and mTwTm are Android developers who can provide assistance to Android App design.
| Android Java/Kotlin
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)]
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)] (mTwTm@mozilla.com), [https://github.com/cnevinc/ Nevin Chen] (nevin@mozilla.com)
|
|-
| Toolkit for sandboxing third-parties libraries in Firefox
| Firefox supports a long tail of infrequently used image and audio formats to
support the occasional website that uses them. Each such format requires the
Firefox decoder to use a new open source library for parsing and decoding.
This, unfortunately, increases the attack surface of Firefox and as we saw in
Pwn2Own 2018, Firefox was successfully exploited via a bugs in such libraries
(libogg in this case).

This project proposes to sandbox third-party libraries in Firefox by building a
new software-fault isolation toolkit. Our tookit will build on the WebAssembly
compiler to isolate libraries in Firefox. But, as part of this toolkit we will
also develop and apply a library for safely interfacing with sandboxed libraries (and
sanitizing data coming from them). with this toolkit we can ensure that any
vulnerability in third-party libraries (e.g., libogg or libpng) cannot be used
to be used to compromise Firefox.
| C/C++, experience with WebAssembly
| [https://mozillians.org/en-US/u/erahm/ Eric Rahm]
| [https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]
|
|-
| Test automation our linting tools
| We have a several linting tools running on Firefox code base, they currently don't have a test suite.
The goal of this project is to make sure that tests are executed. We currently have a similar [https://bugzilla.mozilla.org/show_bug.cgi?id=1432410 test automation for static analyzer jobs]. The idea would be to extend (or replicate) this model for [https://searchfox.org/mozilla-central/source/tools/lint/ ./mach lint] (which run flake8, eslint, etc) and [https://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/mach_commands.py#2327 ./mach clang-format]
The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1448008
| Python
| [https://github.com/sylvestre Sylvestre] (s@mozilla.com)
| [https://github.com/abpostelnicu Andi Postelnicu] (andi@mozilla.com)
|
|-
| Firefox Account Security Dashboard
| Firefox Account administrators and users need an easily digestible view into the important events that have occurred on an account, providing a way to audit for irregularities.
| JavaScript, HTML, CSS, MySQL
| [https://mozillians.org/u/vbudhram/ Vijay Budhram], [https://mozillians.org/u/stomlinson/ Shane Tomlinson]
| [https://mozillians.org/u/vbudhram/ Vijay Budhram], [https://mozillians.org/u/stomlinson/ Shane Tomlinson]
| The Firefox Account platform tracks security information about an account, but does not surface this information in an easily consumable format. Users and administrators should be able to see a timeline of an account’s security related events, such as connecting devices, signing into services, changing or resetting passwords, and adding or removing 2FA. Each event in the timeline should include a timestamp, IP address, and location information when they occurred.

This project would entail updating our security event API to ensure we track and expose the required data. The first phase is to build a script that consumes the API and pretty prints the timeline. The second phase is to provide a web interface for the security timeline.

|-
| Improving FastParquet
| FastParquet is a Python library that needs improvement to how it writes the parquet file format
| Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/klahnakoski/mo-parquet/blob/dev/docs/StudentProject%202019.md Read more]

|-
| Faster Pyparsing
| Pyparsing is a Python library that provides a DSL for language specification. It could use some optimization.
| Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/moz-sql-parser/blob/dev/docs/Student%20Project%202019.md Read more]

|-
| Regression Detection
| Use machine learning to guide statistical model selection, then use the model(s) to detect regressions in future data.
| Machine Learning, Statistics, Python
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski]
| [https://github.com/mozilla/ActiveData/blob/dev/docs/Student%20Project%20190121.md Read more]

|-
| ..your next idea here!
| some details
| skills/language
| reporter
| mentor
| comments

EngineeringProductivity/Projects/ActiveData

2018-02-21T00:11:58Z

Klahnakoski: mention redash

= Overview =

ActiveData is a collection of about 8 billion records (Feb 2016) covering unit tests, Buildbot jobs, performance data, and mercurial. This collection is publicly available, and can be queried directly, similar to any database.

ActiveData is built on top of ElasticSearch, a fast, distributed, redundant document store. ActiveData provides the benefits of familiar and succinct SQL by translating SQL-like queries to ElasticSearch queries,

== Problem ==
In order to improve our testing infrastructure we require data on how that infrastructure is performing. That information can be extracted from the raw logs, but that requires downloading samples, parsing data, insertion into a database (or worse, writing queries in an imperative language, like Python). When we are done an analysis we have effectively built an ETL pipeline that does not scale, and is too specific to be reused elsewhere. The next project does this work all over again.

== Solution==
ActiveData will serve as a reusable ETL pipeline; annotating the test results with as much relevant data as possible. It also provides a query service to explore and aggregate the data, so there is minimal setup required to access this data.

= Redash =
ActiveData has a Redash connector for [https://sql.telemetry.mozilla.org/ stmo] and it accepts SQL. [https://github.com/mozilla/ActiveData/blob/dev/docs/redash.md see main doc for details]

= Charts =

ActiveData is fast enough to support dashboards.

== Build times ==
{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/End-to-End.html End to End Times]
|| Shows overall time from when a build is first requested to the time tests on that build are complete.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Overview.html Build Times]
|| Time series view of build times by platform and build type. Click on a bar to get a scatter plot view.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Detail.html Detailed Build Times]
|| Scatter plot of build times. Use the left navigation panel to choose a combination. Click on a data point to see the Buildbot step times and Mozharness step times.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Buildbot-Simulator.html Buildbot Simulator] incomplete
|| An incomplete Buildbot scheduling simulator. It can be used to see past wait times, queue size, and inter-job delays.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/index.html Test Runtimes]
|| Choose test suite and machine pool to get an average run time for each of the buildbot steps, and Mozharness steps.
|}

==Unit Test Visualization==
With all unit test results in ActiveData, we can get accurate estimates of "failure rate"; and be able to focus on the most-failing tests.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/index.html Top Intermittent Failures]
|| List of top 30 most-failing unit tests, and list of top 30 most-recent failing tests. Click on the link to get a scatterplot.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/test.html Find Test Results]
|| Use the search bar to find a test. A list of matching tests, and platform combinations will show the unit test failures and durations.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/NeglectedOranges/index.html Neglected Oranges]
|| Cross reference OrangeFactor and Bugzilla to give a list of frequent intermittents that have no bug activity.
|}

= Design =
ActiveData attempts to provide the benefits of an available database to the public; except larger and faster.

== Goals ==
An active data instance distinguishes itself from a static resource, or database, or big data solution, by delivering a particular set of features:
* '''A service, open to third party clients''' - By providing the service, clients don't need to setup their own datastore
* '''Fast filtering''' - Sub-second filtering over the contents of the whole datastore, independent of size, saves the application developer from declaring and managing indexes that do the same: There is sufficient information in the queries to determine which indexes should be built to deliver a quick response.
* '''Fast aggregates''' - Sub-second calculation of statistics over the whole datastore saves the application developer from building and managing caches of those aggregates.
* '''API is a query language (SQL?, MDX?)''' - Building upon the formalisms, and familiarity, of existing query languages, we reduce the learning curve, and also provide Active Data implementations with more insight into the intent of the client application; and optimize for its use cases.
* '''Uniform, Cartesian space of values''' - Mozilla has a mandate of data driven decision making. Data analysis tools, like Spreadsheets, R, Scipy, Numpy, and Pandas are used to perform data analysis, and they all require uniform data in multi-dimensional arrays, commonly known as "pivot tables" or "data frames". ActiveData's objective is to provide query results in these formats
* '''Metadata on dimensions and measures''' - ActiveData also provides context to the data it holds. It serves the purpose to allow exploration and discovery by third parties; by describing unit-of-measure, how dimensions relate to others, and provide human descriptions of the columns stored. This metadata is also invaluable in automating the orientation and formatting of dashboard charts: Knowing the domain of an axis allows code to decide the best (default) chart form, and provides logically reasonable aggregate options.
* '''Has a security model''' - Simpler applications can avoid the complications of a security model if it is baked into the ActiveData solution. If ActiveData is to become mainstream it is important that it can manage sensitive data and PII.

== Limitations ==

The unittest data is limited to those test suites that generate structured logs. Currently (Feb, 2016) the following do NOT have structured logs, and are NOT in ActiveData:

* cppunittest
* and any of the js based gaia suites (e.g Gij)

Specifically, you can see if a structured log is being generated: In Treeherder, click a job. Under the "Job details" pane at the bottom, look for a line similar to:

<blockquote> ''artifact uploaded: <suite>_raw.log''
</blockquote>

If you see that, it is using structured logging.

ActiveData makes specific tradeoffs to achieve its goals. It has the following limitations:
* large memory requirements
* low add/update/remove speeds
* strict data model (snowflake schema, hierarchical relations only)
* non-relational
* ETL work required to de-normalize data
* ETL work required to provide dimension metadata

== Non Goals ==
ActiveData is not meant to replace an application database. Applications often track significantly more data related to good interface design, process sequences, complex relations, and object life cycles.
ActiveData's simple model makes it difficult to track object life cycles and impossible to model many-to-many relations.
Data is not live, and definitely does not track "pending jobs" like TreeHerder or TaskCluster do. Test results may take a day, or more, to be indexed.

= Dependencies / Who will use this =
== Dependencies ==

ActiveData's ETL pipeline ingests data from a variety of sources:

* Buildbot
* Mozharness
* Structured Logs
* Task Cluster (end of Q1 2016)
* PerfHerder
* hg.mozilla.org

== Users ==

ActiveData's primary goal is to support dashboards that give Mozilla useful perspectives into the large amount of data:

* Individual unit test results
* Buildbot test times
* Firefox compile times
* Recently new, removed, and disabled tests
* Buildbot wait times

= Let's Use It! =

The service listens at http://activedata.allizom.org/query and accepts queries in [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md JSON Query Expression format].

curl -XPOST -d "{\"from\":\"unittest\"}" http://activedata.allizom.org/query

== The Query Tool ==
The ActiveData service is intended for use by automated clients, not humans. The [http://activedata.allizom.org/tools/query.html Query Tool] is a minimal web page for humans to do some exploration, and to test phrasing queries.
* [http://activedata.allizom.org/tools/query.html ActiveData QueryTool]

== Documentation ==
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md tutorial]
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Unittest%20Schema.md Unit test results schema]

= Code =
Development is still in the early stages, setting up your own service
* Github: https://github.com/klahnakoski/ActiveData
== Tests ==
* [https://github.com/klahnakoski/ActiveData/blob/master/tests/test_unittests.py testing code which sends some unittest-specific queries]

== Bugs ==
Bug are tracked in [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=activedata Bugzilla]. The open issues are shown here:
<bugzilla>
{
"quicksearch":"activedata"
}
</bugzilla>

= Contact =

* Kyle Lahnakoski
** IRC: ekyle@irc.mozilla.org
** Email: klahnakoski@mozilla.org
** Bugzilla: :ekyle

= More Context=
Mostly rambling, optional reading.

== Inspiration==
This project is inspired by the data warehouse and data mart technology that is common inside large corporations. These warehouses are useful because they are "active" services: This means the data is not only available, but it can be explored interactively by large audience using a query language.

== General Problem ==
A significant portion of any application is the backend database/datastore, which include:
* Managing resources and machines to support the datastore
* Data migrations on schemas during application lifetime
* Manually defining database indexes for responsive data retrieval
* Coding caching logic to reduce application latency

The manual effort put toward these features becomes significant as the amount of data grows in size and complexity. More importantly, this effort is being spent over and over on a multitude of applications, each a trivial variation of the next.

==General Solution==

Abstractly, we desire to reduce this redundant workload by adding a layer of abstraction called ActiveData: Clients using ActiveData benefit from the features it provides and avoid the datastore management complexities. While the ActiveData implementers can focus on these common issues while being given a simpler data model, and simpler query language, upon which to calculate optimizations.

Columnar datastores, have solved many (but not all) problems with changing schema. Query-directed indexing has been around for decades in Oracle's query optimization algorithms, and are available for free in ElasticSearch. We now have the technology to build an ActiveData solution.

By defining an ActiveData standard, we can innovate on both sides of the ActiveData abstraction layer independently

== Client Architecture ==

Applications that leverage an active data warehouse can forgo significant server side development, if not all, and put the logic on the client side.

Auto-tools/Projects/DevelopmentMetrics

2017-07-06T18:04:25Z

Klahnakoski: fix links

== Overview ==

These charts serve two purposes. The first is to satisfy one of the specific needs of the [[Bugzilla Anthropology|Bugzilla Anthropology Project]] which was to provide a view into patch review times. The second is to prove
ElasticSearch can be used a performant [http://en.wikipedia.org/wiki/Data_warehouse data warehouse].
More on the project and conclusions can be found at the [https://wiki.mozilla.org/index.php?title=Bugzilla_Anthropology/2013-01-29 Jan 2013 project summary].
There is also my [https://github.com/klahnakoski/Bugzilla-ETL/blob/v2/docs/Bugzilla%20Lightning%20161207.pdf DashCon presentation]( [https://github.com/klahnakoski/Bugzilla-ETL/blob/v2/docs/Bugzilla%20Lightning%20161207.ppt PPT])

== Bug Counts ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/metrics/Bug-Counts.html Bug Counts] || Open bug count over time, with open/close rates, and median age. Filter bugs by time range, components, and common program markups. This dashboard is meant as a rough-first-step to building something more process specific.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/metrics/Bug-CloseRate.html#sampleInterval=week&sampleMax=2014-01-25&sampleMin=2012-05-27 Bug Close Rate] || Counts bug closures, and requires writing Elasticsearch filters to limit view to desired category of bugs.
|}

==Patch Reviews==

Reviews are broken [https://bugzilla.mozilla.org/show_bug.cgi?id=1344253 see bug 1344253]

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/review/Review-byTop.html Top 30 Reviewers] Requires VPN. Allow mixed content.
| Shows the top reviewers from the past 6 weeks, the number of reviews they did, and the number in their queue right now. The original objective of this dashboard is to confirm some engineers have too many reviews. This dashboard is fine for identifying egregious differences, but poor for individual comparison; it seems personal style, team style, and code under review all impact the size and number of reviews done.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/review/ReviewIntensity_First.html Time to First Incoming Review]
 Requires VPN. Allow mixed content.
| Counts review requests and review completion rates. Also breaks down aggregate review age. The first review has been shown to take the longest, probably due to people synchronization issues. Subsequent reviews were almost instantaneous, so we exclude them. This dashboard is not good for fine grained comparison of teams because the nature of the bugs, and the process used, is often too different. The response time INCLUDES WEEKENDS.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/review/Review-byReviewer.html Incoming Review by Individual] Requires VPN. Allow mixed content.
| Top reviewers, but this time with some breakdown by week and component. Interesting, but not actionable.
|- style="vertical-align:top;"
| [https://charts.mozilla.org/review/ReviewIntensity.html Incoming Reviews]
 Requires VPN. Allow mixed content.
| Statistics for all reviews. Subsequent reviews of a bug happen much faster than the first. Maybe the fast review speed is an administrative anomaly; reviews are added after the fact, and marked as reviewed. Maybe, the requester and reviewer are working closely to remove the remaining nits.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/review/Reviews_Pending_18.html Reviews Requested in the Past 18 weeks]
| An attempt to better understand the aggregate response time; while treating "old" reviews (those over 18weeks), as something else entirely.
|}

==Engineering Dashboards==

Dashboards for use by developers, or our own team

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/NeglectedOranges/index.html Neglected Oranges]
| List of current, intermittent test failures, and have seen no bug activity in the past week.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/platform/dashboard.html Management Dashboard]
| View of all bugs for a particular team, in priority order, and categorized to help understand scope. This prototype was designed in 2015 for the categories important to the JS team.
|}

==Release Management Dashboards==

[https://wiki.mozilla.org/Release_Management Release Management] are responsible for quality, security, and stability.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/platform/releases.html Release Dashboard]
| All outstanding bugs tracked by the Release Management
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/platform-history/release-history.html Release Uplifts]
| Count the number of patches that have been uplifted to the Aurora and Beta branches.
|}

== Contributors ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/contributors/dashboard.html# Contributors Dashboard]
| [https://wiki.mozilla.org/EngineeringProductivity Engineering Productivity's] list of contributor bugs that may benefit from some action on our part.
|}

==Project Dashboards and Burndown==

These dashboards are for showing general project state and burndown.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/quantum/blockers.html Quantum Flow tiles] 
| All components with Quantum Flow bugs (qf:p1), color-coded by age
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/QuantumFlow2/QuantumFlowBurndown.html Quantum Flow Burndown] Requires VPN. Allowed mixed content.
| Quantum Flow bugs (qf:p1) over time, with projected complete date
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/metrics/Dashboard_byProject.html Project Dashboard] Requires VPN. Allowed mixed content.
| Lists assigned bugs, patches in review, and patches awaiting landing
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/metrics/Predictive_Simple.html#programFilter=B2G+1.3 Burndown Prediction] Requires VPN. Allowed mixed content.
| Uses average new bug rate, and average close rate to estimate the time it takes
to close all bugs in the given category. Compares to close rates necessary to meet due date
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/metrics/Dashboard-FinalBurndown.html Final Burndown Dashboard] Requires VPN. Allowed mixed content.
| Basic burndown chart. Showing current bugs over time compared to ideal (linear) burndown
|}

EngineeringProductivity/Projects/ActiveData

2017-07-06T17:54:47Z

Klahnakoski: fix links

= Overview =

ActiveData is a collection of about 8 billion records (Feb 2016) covering unit tests, Buildbot jobs, performance data, and mercurial. This collection is publicly available, and can be queried directly, similar to any database.

ActiveData is built on top of ElasticSearch, a fast, distributed, redundant document store. ActiveData provides the benefits of familiar and succinct SQL by translating SQL-like queries to ElasticSearch queries,

== Problem ==
In order to improve our testing infrastructure we require data on how that infrastructure is performing. That information can be extracted from the raw logs, but that requires downloading samples, parsing data, insertion into a database (or worse, writing queries in an imperative language, like Python). When we are done an analysis we have effectively built an ETL pipeline that does not scale, and is too specific to be reused elsewhere. The next project does this work all over again.

== Solution==
ActiveData will serve as a reusable ETL pipeline; annotating the test results with as much relevant data as possible. It also provides a query service to explore and aggregate the data, so there is minimal setup required to access this data.

= Charts =

ActiveData is fast enough to support dashboards.

== Build times ==
{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/End-to-End.html End to End Times]
|| Shows overall time from when a build is first requested to the time tests on that build are complete.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Overview.html Build Times]
|| Time series view of build times by platform and build type. Click on a bar to get a scatter plot view.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Builds-Detail.html Detailed Build Times]
|| Scatter plot of build times. Use the left navigation panel to choose a combination. Click on a data point to see the Buildbot step times and Mozharness step times.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/Buildbot-Simulator.html Buildbot Simulator] incomplete
|| An incomplete Buildbot scheduling simulator. It can be used to see past wait times, queue size, and inter-job delays.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/MoBuildbotTimings/index.html Test Runtimes]
|| Choose test suite and machine pool to get an average run time for each of the buildbot steps, and Mozharness steps.
|}

==Unit Test Visualization==
With all unit test results in ActiveData, we can get accurate estimates of "failure rate"; and be able to focus on the most-failing tests.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/index.html Top Intermittent Failures]
|| List of top 30 most-failing unit tests, and list of top 30 most-recent failing tests. Click on the link to get a scatterplot.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/testfailures/test.html Find Test Results]
|| Use the search bar to find a test. A list of matching tests, and platform combinations will show the unit test failures and durations.
|-
| style="vertical-align:top;width:300px;" | [https://charts.mozilla.org/NeglectedOranges/index.html Neglected Oranges]
|| Cross reference OrangeFactor and Bugzilla to give a list of frequent intermittents that have no bug activity.
|}

= Design =
ActiveData attempts to provide the benefits of an available database to the public; except larger and faster.

== Goals ==
An active data instance distinguishes itself from a static resource, or database, or big data solution, by delivering a particular set of features:
* '''A service, open to third party clients''' - By providing the service, clients don't need to setup their own datastore
* '''Fast filtering''' - Sub-second filtering over the contents of the whole datastore, independent of size, saves the application developer from declaring and managing indexes that do the same: There is sufficient information in the queries to determine which indexes should be built to deliver a quick response.
* '''Fast aggregates''' - Sub-second calculation of statistics over the whole datastore saves the application developer from building and managing caches of those aggregates.
* '''API is a query language (SQL?, MDX?)''' - Building upon the formalisms, and familiarity, of existing query languages, we reduce the learning curve, and also provide Active Data implementations with more insight into the intent of the client application; and optimize for its use cases.
* '''Uniform, Cartesian space of values''' - Mozilla has a mandate of data driven decision making. Data analysis tools, like Spreadsheets, R, Scipy, Numpy, and Pandas are used to perform data analysis, and they all require uniform data in multi-dimensional arrays, commonly known as "pivot tables" or "data frames". ActiveData's objective is to provide query results in these formats
* '''Metadata on dimensions and measures''' - ActiveData also provides context to the data it holds. It serves the purpose to allow exploration and discovery by third parties; by describing unit-of-measure, how dimensions relate to others, and provide human descriptions of the columns stored. This metadata is also invaluable in automating the orientation and formatting of dashboard charts: Knowing the domain of an axis allows code to decide the best (default) chart form, and provides logically reasonable aggregate options.
* '''Has a security model''' - Simpler applications can avoid the complications of a security model if it is baked into the ActiveData solution. If ActiveData is to become mainstream it is important that it can manage sensitive data and PII.

== Limitations ==

The unittest data is limited to those test suites that generate structured logs. Currently (Feb, 2016) the following do NOT have structured logs, and are NOT in ActiveData:

* cppunittest
* and any of the js based gaia suites (e.g Gij)

Specifically, you can see if a structured log is being generated: In Treeherder, click a job. Under the "Job details" pane at the bottom, look for a line similar to:

<blockquote> ''artifact uploaded: <suite>_raw.log''
</blockquote>

If you see that, it is using structured logging.

ActiveData makes specific tradeoffs to achieve its goals. It has the following limitations:
* large memory requirements
* low add/update/remove speeds
* strict data model (snowflake schema, hierarchical relations only)
* non-relational
* ETL work required to de-normalize data
* ETL work required to provide dimension metadata

== Non Goals ==
ActiveData is not meant to replace an application database. Applications often track significantly more data related to good interface design, process sequences, complex relations, and object life cycles.
ActiveData's simple model makes it difficult to track object life cycles and impossible to model many-to-many relations.
Data is not live, and definitely does not track "pending jobs" like TreeHerder or TaskCluster do. Test results may take a day, or more, to be indexed.

= Dependencies / Who will use this =
== Dependencies ==

ActiveData's ETL pipeline ingests data from a variety of sources:

* Buildbot
* Mozharness
* Structured Logs
* Task Cluster (end of Q1 2016)
* PerfHerder
* hg.mozilla.org

== Users ==

ActiveData's primary goal is to support dashboards that give Mozilla useful perspectives into the large amount of data:

* Individual unit test results
* Buildbot test times
* Firefox compile times
* Recently new, removed, and disabled tests
* Buildbot wait times

= Let's Use It! =

The service listens at http://activedata.allizom.org/query and accepts queries in [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md JSON Query Expression format].

curl -XPOST -d "{\"from\":\"unittest\"}" http://activedata.allizom.org/query

== The Query Tool ==
The ActiveData service is intended for use by automated clients, not humans. The [http://activedata.allizom.org/tools/query.html Query Tool] is a minimal web page for humans to do some exploration, and to test phrasing queries.
* [http://activedata.allizom.org/tools/query.html ActiveData QueryTool]

== Documentation ==
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md tutorial]
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Unittest%20Schema.md Unit test results schema]

= Code =
Development is still in the early stages, setting up your own service
* Github: https://github.com/klahnakoski/ActiveData
== Tests ==
* [https://github.com/klahnakoski/ActiveData/blob/master/tests/test_unittests.py testing code which sends some unittest-specific queries]

== Bugs ==
Bug are tracked in [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=activedata Bugzilla]. The open issues are shown here:
<bugzilla>
{
"quicksearch":"activedata"
}
</bugzilla>

= Contact =

* Kyle Lahnakoski
** IRC: ekyle@irc.mozilla.org
** Email: klahnakoski@mozilla.org
** Bugzilla: :ekyle

= More Context=
Mostly rambling, optional reading.

== Inspiration==
This project is inspired by the data warehouse and data mart technology that is common inside large corporations. These warehouses are useful because they are "active" services: This means the data is not only available, but it can be explored interactively by large audience using a query language.

== General Problem ==
A significant portion of any application is the backend database/datastore, which include:
* Managing resources and machines to support the datastore
* Data migrations on schemas during application lifetime
* Manually defining database indexes for responsive data retrieval
* Coding caching logic to reduce application latency

The manual effort put toward these features becomes significant as the amount of data grows in size and complexity. More importantly, this effort is being spent over and over on a multitude of applications, each a trivial variation of the next.

==General Solution==

Abstractly, we desire to reduce this redundant workload by adding a layer of abstraction called ActiveData: Clients using ActiveData benefit from the features it provides and avoid the datastore management complexities. While the ActiveData implementers can focus on these common issues while being given a simpler data model, and simpler query language, upon which to calculate optimizations.

Columnar datastores, have solved many (but not all) problems with changing schema. Query-directed indexing has been around for decades in Oracle's query optimization algorithms, and are available for free in ElasticSearch. We now have the technology to build an ActiveData solution.

By defining an ActiveData standard, we can innovate on both sides of the ActiveData abstraction layer independently

== Client Architecture ==

Applications that leverage an active data warehouse can forgo significant server side development, if not all, and put the logic on the client side.

BMO/ElasticSearch/History

2017-07-06T17:46:43Z

Klahnakoski: fix link

= History =
Martin Best started the [https://wiki.mozilla.org/Bugzilla_Anthropology Bugzilla Anthropology Project], which initiated a need for dashboarding the vast repository of information contained in Bugzilla. Metrics has setup an ElasticSearch cluster with all the historical meta data on the bugs in Bugzilla. This includes data on security bugs. [https://wiki.mozilla.org/Auto-tools/Projects/DevelopmentMetrics Mozilla now has views of this data]

== Existing Code ==

We would like to increment on [https://github.com/mozilla-metrics/bugzilla_etl existing ETL]. Unfortunately, the complexity of the installation may reduce the number of interested community members. There are six languages involved:

* Manual Process - Running a few command line functions to setup the index, and redirect the alias pointer when done
* bash - For the main ETL loop: Grouping the bugs into 10K groups
* Spoon - A visual programming tool to connect ETL code snippets, data sources, and data sinks
* SQL - To pull data from Bugzilla database directly
* Javascript - Used to write convert the fine-grained delta objects into bug version snapshot records
* Java - Used to push the bug version records into ElasticSearch cluster

== New Design ==

[[File:BMO_ElasticSearch_Architecture.png|300px|thumb|right|Updated June 2014]]

=== Two Clusters: One Public and One Private ===

The new ETL will manage two separate clusters:
* '''Private''' - The first is like the original; containing non-identifying information on all bugs, including security bugs. This cluster will remain behind Mozilla's LDAP.
* '''Public''' - The second is new, and will include all information (including comments) on public bugs. It will be made available to the public for analysis.

=== Justification for Python ===

I believe a Python re-implementation of the existing code benefits community involvement by making the installation procedure simpler, and benefits the ongoing enhancement to code base by enabling unit and functional testing:

* The manual process only exists because the outer loop of ETL is in bash, and it is difficult to perform a dynamic state analysis to fully automate the process. A full Python version will make it easier to probe the existing index state and setup indexes and aliases automatically.
* Kettle (Spoon) is a 700Meg piece of software that is specialized for ETL jobs. Many of it's features are not used in this project. The record-level functions provided by this tool must be learnt to fully interpret the other languages' code.
* The heavy lifting is being done with the main Javascript routine. This can be converted, line-by-line to Python.
* SQL can be imported, without change, to the Python version
* The Java code to push rows to ES is significantly simpler in Python, and easier to maintain
* The current design has no debugging facilities, the Python version will allow stepping through code and easily inspecting intermediate states
* The Python version works better with source control; Spoon uses single-large-XML files which are not split by functional group (but admittedly are well behaved with source control)
* Be able to add tests, with a familiar test framework, and verify correctness

== Update (23 October 2013) ==

The Python ETL is a now functional enough for use. The various servers for the public facing bugs has yet to be setup.

This project took more effort than expected. Here are some of the complications that slowed down development. Please keep in mind I only had a couple months of Python before doing this conversion, feel free to take pleasure at my ignorance:

=== ETL Issues ===
* Python and Javascript property access is different enough to cause a multitude of bugs when just performing naive conversion: For example, converting Javascript <tt>if (!a.b){ ... }</tt> to Python <tt>if not a["b"]: ....</tt> can emit key exceptions and simply take the wrong path when dealing with empty sets.
* Alias analysis is error prone: Users' email addresses can be changed, and there is no record of those changes. The bug activity table has recorded changes for emails that "apparently" do not exist. Well, they do exist, but are aliased. The old ETL used reviews to do some matching. The new version uses the CC lists which have more information. The problem is fundamental corruption in the history caused by (possible) direct poking of the database. This corruption must be mitigated with fuzzy logic.
* It took a while to build up a library of tests that could be used to verify future changes. More tests => more test code => more bugs in test code => more bugs found in production code => more tests. Sometimes it seemed endless.

=== Python Issues ===
* Python is slow. Python speed comes from the C libraries it uses, spending time in the Python interpreter is a bad idea. For example, going through the characters in all strings to check for invalid Unicode turned a slow program into an unusable one. The solution was to find a builtin library that did the work for me (or would raise an exception if the conditions were false). This ETL program has significant data structure transformations that can only be done in Python. The solution was to use the PyPy interpreter.
* PyPy does not work well with C libraries. The C libraries had to be removed in favor of pure Python versions of the same. This was not too hard, except when it came to JSON libraries
* JSON generation is slow: The built-in JSON emitter used generators to convert data structures to a JSON string, but the PyPy optimizer is terrible at analyzing generator code. Furthermore, the JSON libraries available to CPython are incredibly fast (Ujson is by almost 2 orders of magnitude faster!) This made the PyPy version appear inferior despite the speed up in the ETL portion of the code. Part of the solution was to use PyPy's own JSON emitter, but also realize PyPy's default JSON emitter (no pretty printing, no sub-classing, etc) has Ujson speeds. The fastest solution I found so far, is to copy the data structure (with sets, Decimal, and other special types) to one with simple dicts, lists and floats and pass it to the default PyPy JSON emitter[https://github.com/klahnakoski/pyLibrary/blob/61928e3c9b01b823d666bafcc68b90ab2e4199e3/tests/util/test_json_speed.py].
* Python has old-school, unintuitive, routine names (strftime, mktime, randrange, etc) these take time to find, and time to confirm there isn't a better library that should be used instead. I opted to add a facade to most of them to re-envowel their names, and isolate myself from the risk of using the wrong lib (or have it behave in unexpected ways).
* Python2.7 strings are confusing: str() can be either Latin1 or UTF8 encoded, but without any typing to indicate which encoding is used. There are also unicode() strings, which look like strings until you try to compare them: <tt>"é" != u"é"</tt>
* Multithreading was necessary so we can handle multiple network requests at one time, while keeping the code easy to read. Python's threading library is still immature: It has no high level threading constructs to deal with common use cases in an environment that raises exceptions.
* Python2.7 has no exception chaining - added it

In the end we have a high speed ETL solution that is easy to install and execute. There are plenty of improvements that can be made, and definitely in the area of more threads and more multiple processes. But those can wait while we deploy.

== SecReview (20 November 2013) ==

=== Introduction ===

Public Bugzilla data in a publicly accessible ElasticSearch cluster!

* '''Overview''' https://wiki.mozilla.org/Auto-tools/Projects/PublicES
* '''Architecture'''
** PowerPoint https://bugzilla.mozilla.org/attachment.cgi?id=828667
** png version [https://github.com/klahnakoski/Bugzilla-ETL/blob/v2/docs/Architecture.png]
* '''Code''' https://github.com/klahnakoski/Bugzilla-ETL/tree/bzAliases
** '''Main Routine''' https://github.com/klahnakoski/Bugzilla-ETL/blob/bzAliases/bzETL/bz_etl.py#L310
* '''History''' https://wiki.mozilla.org/index.php?title=Bugzilla_Anthropology/2013-01-29

==== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) ====
* Provide '''public''' fast cache of BZ data to:
*# demonstrate current work
*# allow community to build tools
*#* https://github.com/okononen/dash ([http://videos.mozilla.org/uploads/air_mozilla/public/brownbags/2013_11_13_DashboardsUsingElasticSearch.mp4 video])
*#* http://www.joshmatthews.net/bugsahoy/
*#* http://harthur.github.io/bzhome/
*#* http://pike.github.io/beta-dash/
*# allow community to analyze trends, patterns

==== What solutions/approaches were considered other than the proposed solution? ====
* Tried to publicize the existing ES cluster information (private bugs with no comments or summary), but there was concern the CC list may reveal the bug's security category (https://bugzilla.mozilla.org/show_bug.cgi?id=823303)
* Using the BZ-API directly requires sophisticated caching, which appears to stall attempts at making snappy dashboards.

==== Why was this solution chosen? ====
* ElasticSearch is very fast
* Direct DB access leverages existing code
* Direct DB access puts no load on Bugzilla app
* Proven to work with business intelligence queries, which demand fast aggregate data over thousands of bugs (https://wiki.mozilla.org/Bugzilla_Anthropology/2013-01-29)

==== Any security threats already considered in the design and why? ====
* Private bug data leaking into public cluster
* ElasticSearch was not meant for direct public access, proxy added (https://bugzilla.mozilla.org/show_bug.cgi?id=879833)

== Update (January 9th, 2014) ==

Over this past couple of months security reviews have been completed, and the suggested enhancements have been implemented.

=== ETL Highlights ===

==== Alias Analysis ====

All bugs have a carbon copy (CC) list of users that are mailed when the bug changes. The historical record of this list is kept as a list of added and removed email addresses, with timestamps of course. An issue arises when the user changes their email address: The next change in the historical record will refer to the new email address, and not the old, looking something like this:

{|
|'''Time'''||'''Removed'''||'''Added'''||'''Resulting CC List'''
|-
|Jan 2nd|| ||klahnakoski@mozilla.com||klahnakoski@mozilla.com
|-
|Jan 3rd|| ||mcote@mozilla.com||klahnakoski@mozilla.com, mcote@mozilla.com
|-
|Jan 4th||kyle@lahnakoski.com|| ||mcote@mozilla.com
|}

As humans, we know what happened here: Kyle (me) changed his email address (somewhere between Jan2nd and Jan4th), and then removed himself from the CC list for the bug. The ETL script has no such domain knowledge, and simply sees an inconsistency. A naive rebuilding of the CC list history would have to assume '''kyle@lahnakoski.com''' was in the CC list since the beginning (which is a legitimate situation, but uncommon, for the first snapshot of a bug). In aggregate, with all these mismatches, the naive rebuilding of historical record resulted in concluding many bugs started with long CC lists, that were eventually paired down over time to what currently exists. This pattern is quite opposite of reality; where a bug starts with usually few people and the list grows.

I implemented an alias analysis that uses the inconsistency in the history, specifically '''klahnakoski@mozilla.com''' was added to the CC (+1) but does not exist in the current bug state (+0). '''mcote@mozilla.com''' was added (+1) and exists (+1), so the logic is consistent. We must conclude removal is '''kyle@lahnakoski.com''' (-1) matches to addition of '''klahnakoski@mozilla.com''' (+1) to zero effect (0). Really, we are solving a simple equation:

+ k1 + m - k2 == m
=> k1 - k2 == 0
=> k2 == k1

More complex cases involving simply more equations and more unknowns: Then we solve the system of equations. Lucky for us this is not as hard as algebra class because we have many more equations than we have variables to solve for: Finding a solution does not require all equations, and this helps us with the problem of corrupt history.

Corrupt history? - Yes, the older Bugzilla history is slightly corrupted, which can effect the solutions to these equations. To mitigate this problem, the solutions go through a voting stage to help determine what is the truth. In the case of this alias analysis: I found at least three systems of equations where a solution is found, '''and''' that same solution has been found twice as often as any other, then I know there's enough evidence to conclude I have the right solution (one email address matches another).

With alias analysis done, the CC list history looks like they should: Small CC list at the start of a bug's life, growing over time. The alias mapping that results is also used to match review flags (which is another story).

[https://github.com/klahnakoski/Bugzilla-ETL/blob/711810f08951a731dc543c10a0973fc34ed17c6b/bzETL/alias_analysis.py Alias Analysis Code]

==== Proving Correctness ====

Bugzilla contains some bugs that should not be made public. These include bugs with specific security concerns, but also infrastructure specific details and other sensitive items. It is important that these do not leak. Making unit and functional tests is not enough because they can only test the known unknowns. The unknown unknowns are inevitable in any code with reasonable complexity and you can not test for those explicitly. Instead I want to perform the easier task of testing against invariants:

# Private bugs should not be in public cluster
# Private comments should not be in public cluster
# Private attachments should not be in public cluster

To check these tautologies I require datasource that knows what is "private" -- the private cluster has this! It is a simple matter of writing queries that ask for all private entities and check if any are in the public cluster. These queries are computationally expensive because they scan the whole datastore, but the queries are simple enough to be proven correct. Furthermore, these queries can be run outside the main ETL program, allowing us to phase out these expensive checks when we are confident the ETL code is correct.

[https://github.com/klahnakoski/Bugzilla-ETL/blob/88b8d0249cdb4aca1884bd30bed9d11977fc98a9/tests/resources/python/look_for_leaks.py Code to Look for Leaks]

== Reflections (February 5th 2014) ==

My biggest mistakes were in time estimation. Generally, I underestimated communication/coordination overhead, which can be significant:

* '''Security reviews take time''' - The security team was fast and responsive, but it still took time to schedule meetings, and fix the design.
* '''Not much gets done during holidays''' - The holidays are for family and good food, not for production deployment. Assume nothing will get done for two weeks.
* '''Production deployment takes time''' - The IT group responded quickly, but it took time to setup the app, the machines and the configurations. This can be a couple of weeks at least, much of it communication delay and context switching overhead.
* '''Debugging production code is hard''' - If something goes wrong in production, it can be hard to debug.
** Inspecting code for possible bugs that match the problem's signature,
** making a test to validate,
** adding more logging in case you fixed some other bug instead,
** running the battery of tests, and
** scheduling IT to push the next version
: all takes time; a couple of days at least. Compare this to development: where you can squash a bug in an hour.

Another issue, mentioned above, is the extra effort in adding tests to the code-base: More tests => more test code => more bugs in test code => more bugs found in production code => more tests. A very good thing for sure, but I should have recalled from my past that tests account for 2/3 of coding effort. I should have tried to estimate the effort to rewrite the existing code, then doubled it to get an estimate for writing the testing code. I had lazily glossed over that non-trivial amount of effort.

Finally, Python has idiosyncrasies, and the bugs caused by utf8/latin1 were the most time consuming.

EngineeringProductivity/Projects/Stockwell/Meetings/2017-05-23

2017-05-23T15:48:52Z

Klahnakoski: add some links

= Previous Action Items =

= Status =
* OF:
** last week: 7.81
** 4 weeks ago: 6.64

* high frequency intermittents
** last week: 41
** 4 weeks ago: 31

* if all high frequencies were fixed, OF would be...?
** last week: 4.65
** 4 weeks ago: 4.75

* year to date: 233 fixed, 122 disabled (disabled is 34.3% vs 35.15% 2 weeks ago)
= Discussion Topics =
* Talk about Orange Factor, NeglectedOranges
** https://people-mozilla.org/~klahnakoski/NeglectedOranges/index.html
** https://people-mozilla.org/~klahnakoski/testfailures/test.html#search=devtools/client/netmonitor/test/browser_net_statistics-02.js&sampleMax=2017-05-23&sampleMin=2017-05-10
** https://people-mozilla.org/~klahnakoski/testfailures/test.html#search=/html/browsers/the-window-object/apis-for-creating-and-navigating-browsing-contexts-by-name/open-features-tokenization-screenx-screeny.html&sampleMax=2017-05-23&sampleMin=2017-05-10
*

= New Ideas to investigate =
*

= Action Items =
* Discussion topics for next time
**
**
*

EngineeringProductivity/Projects/Stockwell/Meetings/2017-04-25

2017-04-25T20:34:26Z

Klahnakoski: add intermittent counts

= Previous Action Items =

= Status =
* OF:
** last week: 6.64
** 4 weeks ago: 10.08

* high frequency intermittents
** last week 31
** 4 weeks ago 55

* if all high frequencies were fixed, OF would be...?
** 4.75
** 5.13

* year to date: 198 fixed, 110 disabled (disabled is 35.7% vs 34.9% 1 month ago)

= Discussion Topics =
* [gbrown] Starting to look at "new/modified test verification" - {{bug|1357513}}
** overall great idea, web-platform does this on upstream new tests, 10x per test
** keep it small, don't do dependent files, or run randomization/high resource programs in the background
** how to track the effectiveness of this:
*** whiteboard tags for intermittents related to test changes
*** build a dashboard for recent changes which are 5+ intermittents in a week
* [gbrown] Trying to enable eslint on more tests - {{bug|1357557}}
** will spend a few days hacking on this to see how easy this is to make a big sweep through the tree
** might be tough to whitelist existing failures or only run on new changes.
* [jmaher] Lifecycle of managing intermittents today
** 3 sources:
*** [https://brasstacks.mozilla.com/orangefactor/index.html overall OF] (looking for missing stockwell tags)
*** [https://people.mozilla.org/~klahnakoski/NeglectedOranges/index.html neglected]
*** [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=%5Bstockwell%20needswork%5D&list_id=13546073 needswork]
*** [gbrown] reduced OF to the last day or two to find most recent troublemakers
** is there value to retriggering to identify the root cause
* [jmaher] Roadmap for autoclassification in Q2/Q3 ? (how can we track what is auto classified vs not)
** query the treeherder db for what is autoclassified- should experiment with this and propose an api
** Show all intermittents, with auto-classify count, for past week: https://activedata.allizom.org/tools/query.html#query_id=QaxkaHye

{
"from":"treeherder",
"select":[
{"aggregate":"count"},
{
"name":"is_auto",
"value":{
"when":{"in":[
{"literal":"autoclassified intermittent"},
"failure.notes.failure_classification"
]},
"then":1,
"else":0
},
"aggregate":"sum"
}
],
"edges":"bugs.bug_id",
"where":{"and":[
{"eq":{"failure.notes.failure_classification":"intermittent"}},
{"gt":{"last_modified":{"date":"today-week"}}},
{"ne":{"repo.branch.name":"try"}}
]},
"limit":10000
}

= New Ideas to investigate =
*

= Action Items =
* Discussion topics for next time
**
**
*

Auto-tools/Projects/DevelopmentMetrics

2017-04-24T22:19:53Z

Klahnakoski: less words

== Overview ==

These charts serve two purposes. The first is to satisfy one of the specific needs of the [[Bugzilla Anthropology|Bugzilla Anthropology Project]] which was to provide a view into patch review times. The second is to prove
ElasticSearch can be used a performant [http://en.wikipedia.org/wiki/Data_warehouse data warehouse].
More on the project and conclusions can be found at the [https://wiki.mozilla.org/index.php?title=Bugzilla_Anthropology/2013-01-29 Jan 2013 project summary].
There is also my [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pdf DashCon presentation]( [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pptx PPT])

== Bug Counts ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-Counts.html Bug Counts] || Open bug count over time, with open/close rates, and median age. Filter bugs by time range, components, and common program markups. This dashboard is meant as a rough-first-step to building something more process specific.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-CloseRate.html#sampleInterval=week&sampleMax=2014-01-25&sampleMin=2012-05-27 Bug Close Rate] || Counts bug closures, and requires writing Elasticsearch filters to limit view to desired category of bugs.
|}

==Patch Reviews==

Reviews are broken [https://bugzilla.mozilla.org/show_bug.cgi?id=1344253 see bug 1344253]

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byTop.html Top 30 Reviewers] Requires VPN. Allow mixed content.
| Shows the top reviewers from the past 6 weeks, the number of reviews they did, and the number in their queue right now. The original objective of this dashboard is to confirm some engineers have too many reviews. This dashboard is fine for identifying egregious differences, but poor for individual comparison; it seems personal style, team style, and code under review all impact the size and number of reviews done.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity_First.html Time to First Incoming Review]
 Requires VPN. Allow mixed content.
| Counts review requests and review completion rates. Also breaks down aggregate review age. The first review has been shown to take the longest, probably due to people synchronization issues. Subsequent reviews were almost instantaneous, so we exclude them. This dashboard is not good for fine grained comparison of teams because the nature of the bugs, and the process used, is often too different. The response time INCLUDES WEEKENDS.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byReviewer.html Incoming Review by Individual] Requires VPN. Allow mixed content.
| Top reviewers, but this time with some breakdown by week and component. Interesting, but not actionable.
|- style="vertical-align:top;"
| [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity.html Incoming Reviews]
 Requires VPN. Allow mixed content.
| Statistics for all reviews. Subsequent reviews of a bug happen much faster than the first. Maybe the fast review speed is an administrative anomaly; reviews are added after the fact, and marked as reviewed. Maybe, the requester and reviewer are working closely to remove the remaining nits.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Reviews_Pending_18.html Reviews Requested in the Past 18 weeks]
| An attempt to better understand the aggregate response time; while treating "old" reviews (those over 18weeks), as something else entirely.
|}

==Engineering Dashboards==

Dashboards for use by developers, or our own team

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://people.mozilla.org/~klahnakoski/NeglectedOranges/index.html Neglected Oranges]
| List of current, intermittent test failures, and have seen no bug activity in the past week.
|-
| style="vertical-align:top;width:300px;" | [https://people-mozilla.org/~klahnakoski/platform/dashboard.html Management Dashboard]
| View of all bugs for a particular team, in priority order, and categorized to help understand scope. This prototype was designed in 2015 for the categories important to the JS team.
|}

==Release Management Dashboards==

[https://wiki.mozilla.org/Release_Management Release Management] are responsible for quality, security, and stability.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform/releases.html Release Dashboard]
| All outstanding bugs tracked by the Release Management
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform-history/release-history.html Release Uplifts]
| Count the number of patches that have been uplifted to the Aurora and Beta branches.
|}

== Contributors ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/contributors/dashboard.html# Contributors Dashboard]
| [https://wiki.mozilla.org/EngineeringProductivity Engineering Productivity's] list of contributor bugs that may benefit from some action on our part.
|}

==Project Dashboards and Burndown==

These dashboards are for showing general project state and burndown.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://people-mozilla.org/~klahnakoski/quantum/blockers.html Quantum Flow tiles] 
| All components with Quantum Flow bugs (qf:p1), color-coded by age
|-
| style="vertical-align:top;width:300px;" | [https://people-mozilla.org/~klahnakoski/QuantumFlow2/QuantumFlowBurndown.html Quantum Flow Burndown] Requires VPN. Allowed mixed content.
| Quantum Flow bugs (qf:p1) over time, with projected complete date
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard_byProject.html Project Dashboard] Requires VPN. Allowed mixed content.
| Lists assigned bugs, patches in review, and patches awaiting landing
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Predictive_Simple.html#programFilter=B2G+1.3 Burndown Prediction] Requires VPN. Allowed mixed content.
| Uses average new bug rate, and average close rate to estimate the time it takes
to close all bugs in the given category. Compares to close rates necessary to meet due date
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard-FinalBurndown.html Final Burndown Dashboard] Requires VPN. Allowed mixed content.
| Basic burndown chart. Showing current bugs over time compared to ideal (linear) burndown
|}

Auto-tools/Projects/DevelopmentMetrics

2017-04-24T22:17:46Z

Klahnakoski: mention the reviews are broken

== Overview ==

These charts serve two purposes. The first is to satisfy one of the specific needs of the [[Bugzilla Anthropology|Bugzilla Anthropology Project]] which was to provide a view into patch review times. The second is to prove
ElasticSearch can be used a performant [http://en.wikipedia.org/wiki/Data_warehouse data warehouse].
More on the project and conclusions can be found at the [https://wiki.mozilla.org/index.php?title=Bugzilla_Anthropology/2013-01-29 Jan 2013 project summary].
There is also my [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pdf DashCon presentation]( [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pptx PPT])

== Bug Counts ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-Counts.html Bug Counts] || Open bug count over time, with open/close rates, and median age. Filter bugs by time range, components, and common program markups. This dashboard is meant as a rough-first-step to building something more process specific.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-CloseRate.html#sampleInterval=week&sampleMax=2014-01-25&sampleMin=2012-05-27 Bug Close Rate] || Counts bug closures, and requires writing Elasticsearch filters to limit view to desired category of bugs.
|}

==Patch Reviews==

Reviews are broken [https://bugzilla.mozilla.org/show_bug.cgi?id=1344253 see bug 1344253]

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byTop.html Top 30 Reviewers] Requires VPN and disabled mixed content blocking
| Shows the top reviewers from the past 6 weeks, the number of reviews they did, and the number in their queue right now. The original objective of this dashboard is to confirm some engineers have too many reviews. This dashboard is fine for identifying egregious differences, but poor for individual comparison; it seems personal style, team style, and code under review all impact the size and number of reviews done.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity_First.html Time to First Incoming Review]
 Requires VPN and disabled mixed content blocking
| Counts review requests and review completion rates. Also breaks down aggregate review age. The first review has been shown to take the longest, probably due to people synchronization issues. Subsequent reviews were almost instantaneous, so we exclude them. This dashboard is not good for fine grained comparison of teams because the nature of the bugs, and the process used, is often too different. The response time INCLUDES WEEKENDS.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byReviewer.html Incoming Review by Individual] Requires VPN and disabled mixed content blocking
| Top reviewers, but this time with some breakdown by week and component. Interesting, but not actionable.
|- style="vertical-align:top;"
| [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity.html Incoming Reviews]
 Requires VPN and disabled mixed content blocking
| Statistics for all reviews. Subsequent reviews of a bug happen much faster than the first. Maybe the fast review speed is an administrative anomaly; reviews are added after the fact, and marked as reviewed. Maybe, the requester and reviewer are working closely to remove the remaining nits.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Reviews_Pending_18.html Reviews Requested in the Past 18 weeks]
| An attempt to better understand the aggregate response time; while treating "old" reviews (those over 18weeks), as something else entirely.
|}

==Engineering Dashboards==

Dashboards for use by developers, or our own team

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://people.mozilla.org/~klahnakoski/NeglectedOranges/index.html Neglected Oranges]
| List of current, intermittent test failures, and have seen no bug activity in the past week.
|-
| style="vertical-align:top;width:300px;" | [https://people-mozilla.org/~klahnakoski/platform/dashboard.html Management Dashboard]
| View of all bugs for a particular team, in priority order, and categorized to help understand scope. This prototype was designed in 2015 for the categories important to the JS team.
|}

==Release Management Dashboards==

[https://wiki.mozilla.org/Release_Management Release Management] are responsible for quality, security, and stability.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform/releases.html Release Dashboard]
| All outstanding bugs tracked by the Release Management
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform-history/release-history.html Release Uplifts]
| Count the number of patches that have been uplifted to the Aurora and Beta branches.
|}

== Contributors ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/contributors/dashboard.html# Contributors Dashboard]
| [https://wiki.mozilla.org/EngineeringProductivity Engineering Productivity's] list of contributor bugs that may benefit from some action on our part.
|}

==Project Dashboards and Burndown==

These dashboards are for showing general project state and burndown.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://people-mozilla.org/~klahnakoski/quantum/blockers.html Quantum Flow tiles] 
| All components with Quantum Flow bugs (qf:p1), color-coded by age
|-
| style="vertical-align:top;width:300px;" | [https://people-mozilla.org/~klahnakoski/QuantumFlow2/QuantumFlowBurndown.html Quantum Flow Burndown] Requires VPN. Allowed mixed content.
| Quantum Flow bugs (qf:p1) over time, with projected complete date
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard_byProject.html Project Dashboard] Requires VPN. Allowed mixed content.
| Lists assigned bugs, patches in review, and patches awaiting landing
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Predictive_Simple.html#programFilter=B2G+1.3 Burndown Prediction] Requires VPN. Allowed mixed content.
| Uses average new bug rate, and average close rate to estimate the time it takes
to close all bugs in the given category. Compares to close rates necessary to meet due date
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard-FinalBurndown.html Final Burndown Dashboard] Requires VPN. Allowed mixed content.
| Basic burndown chart. Showing current bugs over time compared to ideal (linear) burndown
|}

Auto-tools/Projects/DevelopmentMetrics

2017-04-24T22:12:34Z

Klahnakoski: add dashboard link

== Overview ==

These charts serve two purposes. The first is to satisfy one of the specific needs of the [[Bugzilla Anthropology|Bugzilla Anthropology Project]] which was to provide a view into patch review times. The second is to prove
ElasticSearch can be used a performant [http://en.wikipedia.org/wiki/Data_warehouse data warehouse].
More on the project and conclusions can be found at the [https://wiki.mozilla.org/index.php?title=Bugzilla_Anthropology/2013-01-29 Jan 2013 project summary].
There is also my [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pdf DashCon presentation]( [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pptx PPT])

== Bug Counts ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-Counts.html Bug Counts] || Open bug count over time, with open/close rates, and median age. Filter bugs by time range, components, and common program markups. This dashboard is meant as a rough-first-step to building something more process specific.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-CloseRate.html#sampleInterval=week&sampleMax=2014-01-25&sampleMin=2012-05-27 Bug Close Rate] || Counts bug closures, and requires writing Elasticsearch filters to limit view to desired category of bugs.
|}

==Patch Reviews==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byTop.html Top 30 Reviewers] Requires VPN and disabled mixed content blocking
| Shows the top reviewers from the past 6 weeks, the number of reviews they did, and the number in their queue right now. The original objective of this dashboard is to confirm some engineers have too many reviews. This dashboard is fine for identifying egregious differences, but poor for individual comparison; it seems personal style, team style, and code under review all impact the size and number of reviews done.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity_First.html Time to First Incoming Review]
 Requires VPN and disabled mixed content blocking
| Counts review requests and review completion rates. Also breaks down aggregate review age. The first review has been shown to take the longest, probably due to people synchronization issues. Subsequent reviews were almost instantaneous, so we exclude them. This dashboard is not good for fine grained comparison of teams because the nature of the bugs, and the process used, is often too different. The response time INCLUDES WEEKENDS.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byReviewer.html Incoming Review by Individual] Requires VPN and disabled mixed content blocking
| Top reviewers, but this time with some breakdown by week and component. Interesting, but not actionable.
|- style="vertical-align:top;"
| [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity.html Incoming Reviews]
 Requires VPN and disabled mixed content blocking
| Statistics for all reviews. Subsequent reviews of a bug happen much faster than the first. Maybe the fast review speed is an administrative anomaly; reviews are added after the fact, and marked as reviewed. Maybe, the requester and reviewer are working closely to remove the remaining nits.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Reviews_Pending_18.html Reviews Requested in the Past 18 weeks]
| An attempt to better understand the aggregate response time; while treating "old" reviews (those over 18weeks), as something else entirely.
|}

==Engineering Dashboards==

Dashboards for use by developers, or our own team

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://people.mozilla.org/~klahnakoski/NeglectedOranges/index.html Neglected Oranges]
| List of current, intermittent test failures, and have seen no bug activity in the past week.
|-
| style="vertical-align:top;width:300px;" | [https://people-mozilla.org/~klahnakoski/platform/dashboard.html Management Dashboard]
| View of all bugs for a particular team, in priority order, and categorized to help understand scope. This prototype was designed in 2015 for the categories important to the JS team.
|}

==Release Management Dashboards==

[https://wiki.mozilla.org/Release_Management Release Management] are responsible for quality, security, and stability.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform/releases.html Release Dashboard]
| All outstanding bugs tracked by the Release Management
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform-history/release-history.html Release Uplifts]
| Count the number of patches that have been uplifted to the Aurora and Beta branches.
|}

== Contributors ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/contributors/dashboard.html# Contributors Dashboard]
| [https://wiki.mozilla.org/EngineeringProductivity Engineering Productivity's] list of contributor bugs that may benefit from some action on our part.
|}

==Project Dashboards and Burndown==

These dashboards are for showing general project state and burndown.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://people-mozilla.org/~klahnakoski/quantum/blockers.html Quantum Flow tiles] 
| All components with Quantum Flow bugs (qf:p1), color-coded by age
|-
| style="vertical-align:top;width:300px;" | [https://people-mozilla.org/~klahnakoski/QuantumFlow2/QuantumFlowBurndown.html Quantum Flow Burndown] Requires VPN. Allowed mixed content.
| Quantum Flow bugs (qf:p1) over time, with projected complete date
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard_byProject.html Project Dashboard] Requires VPN. Allowed mixed content.
| Lists assigned bugs, patches in review, and patches awaiting landing
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Predictive_Simple.html#programFilter=B2G+1.3 Burndown Prediction] Requires VPN. Allowed mixed content.
| Uses average new bug rate, and average close rate to estimate the time it takes
to close all bugs in the given category. Compares to close rates necessary to meet due date
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard-FinalBurndown.html Final Burndown Dashboard] Requires VPN. Allowed mixed content.
| Basic burndown chart. Showing current bugs over time compared to ideal (linear) burndown
|}

Auto-tools/Projects/DevelopmentMetrics

2017-04-24T22:07:45Z

Klahnakoski: add more links

== Overview ==

These charts serve two purposes. The first is to satisfy one of the specific needs of the [[Bugzilla Anthropology|Bugzilla Anthropology Project]] which was to provide a view into patch review times. The second is to prove
ElasticSearch can be used a performant [http://en.wikipedia.org/wiki/Data_warehouse data warehouse].
More on the project and conclusions can be found at the [https://wiki.mozilla.org/index.php?title=Bugzilla_Anthropology/2013-01-29 Jan 2013 project summary].
There is also my [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pdf DashCon presentation]( [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pptx PPT])

== Bug Counts ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-Counts.html Bug Counts] || Open bug count over time, with open/close rates, and median age. Filter bugs by time range, components, and common program markups. This dashboard is meant as a rough-first-step to building something more process specific.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-CloseRate.html#sampleInterval=week&sampleMax=2014-01-25&sampleMin=2012-05-27 Bug Close Rate] || Counts bug closures, and requires writing Elasticsearch filters to limit view to desired category of bugs.
|}

==Patch Reviews==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byTop.html Top 30 Reviewers] Requires VPN and disabled mixed content blocking
| Shows the top reviewers from the past 6 weeks, the number of reviews they did, and the number in their queue right now. The original objective of this dashboard is to confirm some engineers have too many reviews. This dashboard is fine for identifying egregious differences, but poor for individual comparison; it seems personal style, team style, and code under review all impact the size and number of reviews done.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity_First.html Time to First Incoming Review]
 Requires VPN and disabled mixed content blocking
| Counts review requests and review completion rates. Also breaks down aggregate review age. The first review has been shown to take the longest, probably due to people synchronization issues. Subsequent reviews were almost instantaneous, so we exclude them. This dashboard is not good for fine grained comparison of teams because the nature of the bugs, and the process used, is often too different. The response time INCLUDES WEEKENDS.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byReviewer.html Incoming Review by Individual] Requires VPN and disabled mixed content blocking
| Top reviewers, but this time with some breakdown by week and component. Interesting, but not actionable.
|- style="vertical-align:top;"
| [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity.html Incoming Reviews]
 Requires VPN and disabled mixed content blocking
| Statistics for all reviews. Subsequent reviews of a bug happen much faster than the first. Maybe the fast review speed is an administrative anomaly; reviews are added after the fact, and marked as reviewed. Maybe, the requester and reviewer are working closely to remove the remaining nits.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Reviews_Pending_18.html Reviews Requested in the Past 18 weeks]
| An attempt to better understand the aggregate response time; while treating "old" reviews (those over 18weeks), as something else entirely.
|}

==Engineering Dashboards==

Dashboards for use by developers, or our own team

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://people.mozilla.org/~klahnakoski/NeglectedOranges/index.html Neglected Oranges]
| List of current, intermittent test failures, and have een no bug activity in the past week.
|}

==Release Management Dashboards==

[https://wiki.mozilla.org/Release_Management Release Management] are responsible for quality, security, and stability.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform/releases.html Release Dashboard]
| All outstanding bugs tracked by the Release Management
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform-history/release-history.html Release Uplifts]
| Count the number of patches that have been uplifted to the Aurora and Beta branches.
|}

== Contributors ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/contributors/dashboard.html# Contributors Dashboard]
| [https://wiki.mozilla.org/EngineeringProductivity Engineering Productivity's] list of contributor bugs that may benefit from some action on our part.
|}

==Project Dashboards and Burndown==

These dashboards are for showing general project state and burndown.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://people-mozilla.org/~klahnakoski/quantum/blockers.html Quantum Flow tiles] 
| All components with Quantum Flow bugs (qf:p1), color-coded by age
|-
| style="vertical-align:top;width:300px;" | [https://people-mozilla.org/~klahnakoski/QuantumFlow2/QuantumFlowBurndown.html Quantum Flow Burndown] Requires VPN. Allowed mixed content.
| Quantum Flow bugs (qf:p1) over time, with projected complete date
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard_byProject.html Project Dashboard] Requires VPN. Allowed mixed content.
| Lists assigned bugs, patches in review, and patches awaiting landing
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Predictive_Simple.html#programFilter=B2G+1.3 Burndown Prediction] Requires VPN. Allowed mixed content.
| Uses average new bug rate, and average close rate to estimate the time it takes
to close all bugs in the given category. Compares to close rates necessary to meet due date
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard-FinalBurndown.html Final Burndown Dashboard] Requires VPN. Allowed mixed content.
| Basic burndown chart. Showing current bugs over time compared to ideal (linear) burndown
|}

Outreachy

2017-03-10T14:26:31Z

Klahnakoski: add link to the live document

{{Admon/note|Attention Round 14 Applicants:|Projects are now open and taking submissions. Check out the projects below and contact the project mentor, if interested in making a contribution. The application period closes March 30. Visit [https://wiki.gnome.org/Outreachy/2017/MayAugust#Participating_Organizations The GNOME wiki] for more program information.}} 

Mozilla has participated in the Outreachy program for several years. The goals of the program are to increase participation from under-represented groups in free and open source software. Participation is open:
* internationally to all women (cis and trans), trans men, and genderqueer people
* also open in the U.S. to all Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander people

We provide a supportive community for beginning to contribute any time throughout the year and offer three month paid contribution opportunities twice a year.

==Useful links for More Information==
* https://wiki.gnome.org/OutreachProgramForWomen
* https://gnome.org/opw/
* [[GNOME OPW Handbook]]
* [http://kernelnewbies.org/OPWMentor Information for mentors, from Linux Kernel project]

==Outreachy Program Cohort: Round 14 (May 30 -Aug 30, 2017)==

====Page Shot / Screenshotting in Firefox====
'''Mentor:''' [https://mozillians.org/en-US/u/ianbicking/ Ian Bicking] 
'''IRC:''' ianbicking (usually online 8am-3pm Pacific time) 
'''IRC channel:''' [https://kiwiirc.com/client/irc.mozilla.org/pageshot #pageshot]

'''Project Description:'''
[https://github.com/mozilla-services/pageshot/ Page Shot], a screenshot tool for Firefox, will be shipping with Firefox mid-June. Our small team's focus during the time of the internship will be running A/B tests on the product and refining the experience based on what we learn.

There's several areas that can be impactful to the project:
* We are collecting behavioral data on how people use the tool, and plan to make changes through the summer based on what we learn. Someone with skills and interest in analyzing this kind of data (in our case Google Analytics and survey data) would be great. Some of what we want to learn from the data may require data analysis outside of Google Analytics.
* We have many product goals. Page Shot is built as a WebExtension using pretty straight-forward JavaScript. The server is built with Node.js and React. Someone with knowledge of JavaScript together with HTML/CSS can get in and make positive changes quickly.
* Our basic experience will be in place by the summer, but there will be many opportunities for optimizing the performance and size of the screenshots and pages that we're delivering, including offline access. In addition to development skills this will require research and experimentation to plan out the best approach.

If you are interested please [https://github.com/mozilla-services/pageshot/ check out the repository] and try to follow the instructions. If you have problems that's okay! We want to make setup easy for everyone, but we still have work to do. Come to the [https://kiwiirc.com/client/irc.mozilla.org/pageshot IRC channel] so we can help get you setup and improve the experience for future people. We have a [https://github.com/mozilla-services/pageshot/labels/good%20first%20bug list of good first bugs]. If you want to start on one, please get your development environment setup first, and after that comment on a bug that you intend to work on it.

Note that the Page Shot developers work during the day, in timezones from UTC-8 to UTC-5. If an applicant can't work during many of those hours it is unlikely to be a good fit.

====HTML+CSS demos of our new browser engine====
'''Mentor:'''[https://mozillians.org/en-US/u/linclark/ Lin Clark] 
'''IRC:''' linclark

'''Project Description:'''
At Mozilla, we're making our browser faster. This started as a research effort, building a next generation browser engine called Servo. Now parts of Servo are being merged into Firefox with Project Quantum.

The numbers are promising. For example, the new CSS style system (Stylo) can reduce the time it takes to render a page (like Barack Obama's wikipedia page) from 130ms to 30ms.

We want to show this off. In this internship, you'd be making demos that catch people's attention and show off these performance improvements.

For this internship, you will need HTML and CSS skills. We would love to see demos or prototypes you have created in the past that delight and surprise. An understanding of web page performance and how to analyze performance in the browser is preferred but not required.

====Security audit of Firefox code====
'''Mentor:''' [https://mozillians.org/en-US/u/arroway/ Stéphanie Ouillon] 
'''IRC:''' arroway

'''Project Description:'''
The Security Engineering team works on building and ensuring security into Firefox. Part of this work involves conducting security audits of the code shipped in Firefox. The candidate should be comfortable reading C++ and JavaScript Firefox code, and have an interest in learning about security engineering.

The scope of this project includes two main areas we're putting focus on:

1) Security auditing of third-party libraries used in Firefox
Firefox relies on a vast amount of third-party Open Source libraries. Code review and security practices vary from one library to another, or new releases with security fixes might go unnoticed. We want to reduce the risk of including unsafe code in Firefox and auditing more thoroughly the most critical libraries we use.

Tasks include:
* Identifying libraries with security concerns
* Identifying code paths for additional fuzzing
* Documenting the current process for using a new third-party library in mozilla-central
* Setting security metrics (e.g number of security bugs related to the lib) to measure risk associated with a certain lib

2) Sandbox auditing
Firefox is getting a security sandbox (https://wiki.mozilla.org/Security/Sandbox/Process_model). Hardening Firefox against attacks involves:
* Checking IPC mechanisms are safe
* Fuzzing IPC for bugs
* Reviewing Firefox components with respect to sandbox controls

To get started, please visit this page: [https://wiki.mozilla.org/SecOutreachy https://wiki.mozilla.org/SecOutreachy]

====Implement Telemetry health ping====
'''Mentor:''' [https://mozillians.org/en-US/u/gfritzsche/ Georg Fritzsche] 
'''IRC:''' gfritzsche

'''Project Description'''
Firefox Telemetry enables engineers and decision-makers to measure how Firefox behaves in the real world. As you use Firefox, Telemetry measures and collects non-personal information, such as performance, hardware, usage and customizations.

To more reliably monitor the quality of our incoming data and error conditions, we want to implement a small & minimal Telemetry health ping. This will be small enough to be sent without bandwidth concerns and include essential information about failures.

For this project, you will need:
* JavaScript for the Firefox implementation
* Python for processing and validating the incoming data using PySpark

This project will involve:
* working with team members on the design of the health reporting
* implementing the new design on the client, including test coverage
* working with QA on a test plan for the reporting
* validating incoming data
* working with team members to make the data available in our re:dash instance

You can find more details on the [[Telemetry/Outreachy:HealthPing|project page]].

====Improve cross-browser and functional testing for webcompat.com====
'''Mentor:''' [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor] (Note: will be on PTO from March 9 - 19, but will check email sporadically. @karlcow has agreed to help with PRs and in issues). 
'''IRC:''' miketaylr (I can be found in the #webcompat channel. If my nick is zz_miketaylr, I'm away but will get your messages when I come back!).

'''Project Description:'''
webcompat.com is an open source project and website with the ambitious goal of making the web work for all users, in any browser. We want to improve our functional and cross-browser testing capabilities.

In this project, the Outreachy participant will work on the following:

* Define a cross-browser testing matrix
* Get functional tests running in non-Firefox browsers
* Make improvements to BrowserStack - Travis CI Integration (this may or may not be done by the time this Outreachy round starts, we'll see!)
* Create a working sub-set of tests for external contributors without access to authentication secrets.
* Create a script to "bootstrap" a test repo to meet current functional test expectations
* Improve test coverage (writing new functional tests, refactoring existing ones)
* Implement a solution for mocking GitHub authentication
* Investigate intermittent Intern failures
* Explore unit testing with Intern

To be successful, the participant will need to be comfortable writing JavaScript and configuring 3rd party testing services. Some Python and Node.js experience will prove useful, but the rest can be learned!

To get started:

1. [https://github.com/webcompat/webcompat.com/ Clone the repo]
2. [https://github.com/webcompat/webcompat.com/blob/master/CONTRIBUTING.md Set up a local development environment]
3. [https://github.com/webcompat/webcompat.com/blob/master/CONTRIBUTING.md#running-tests Get functional tests running locally]
4. [http://github.com/webcompat/webcompat.com/issues/new Report any bugs or problems you ran into with that process], if any.
5. Send an email to miket@mozilla.com with a screenshot showing tests have completed locally. We'll talk about next contribution steps!
(Note: it's OK if many of them are failing, as long as they all run!)

====Site permission management UI====
'''Mentor:''' [https://mozillians.org/en-US/u/johannh/ Johann Hofmann] 
'''IRC:''' johannh

'''Project Description:'''
"We would like to add a section to Firefox preferences that allows users to manage their saved site permissions (Geolocation, Camera, Microphone, ...). Our UX team is currently designing a nice-looking UI for this. Features include viewing and removing permissions and globally disabling access to a certain permission for all sites. Your task would be to implement this UI inside the Firefox preferences using JavaScript, HTML and CSS and wire up any missing pieces in the Firefox internals (moderate JavaScript experience is recommended).

You might enjoy this project if you like working on user interfaces, care about privacy and security and want to have a sizeable impact on the privacy and security of millions of Firefox users.

You can get started by solving any good first Firefox bug:
* Get Firefox up and running (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build)
* Find a bug to work on (https://www.joshmatthews.net/bugsahoy/?ff=1&unowned=1&simple=1)
* Leave a comment that you want to be assigned and ask about anything that is unclear to you
* Submit your patch (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch)

More details can be found in our contributing guide: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction

It is highly recommended that you hop on IRC (https://wiki.mozilla.org/IRC) and join the #fx-team channel. Feel free to ask for help there (ping johannh).

====CSS Layout Bug Squasher====
'''Mentor:''' [https://mozillians.org/en-US/u/jdm/ Josh Matthews] 
'''IRC:''' jdm

'''Project Description:'''
Servo is a new, experimental web browser engine written in the Rust programming language (http://www.rust-lang.org/). It also has lots of bugs in its implementation of CSS layout. Some of these bugs are filed in the issue tracker with minimized test cases (https://github.com/servo/servo/issues/14947), while others have not been investigated yet (https://github.com/servo/servo/issues/15432). We’re looking for someone who is:

* comfortable writing code in any programming language
* experienced in reading and understanding the effects of CSS

We want to teach you how to write Rust code so you can channel that experience into squashing CSS layout implementation bugs in Servo. You will gain experience in:

* reducing problems into minimal test cases
* developing in a low-level programming language
* using debugging strategies to determine the cause of problems in complex code
* contributing to a large open-source project as part of a distributed team

To get involved:

* clone and build the code (https://github.com/servo/servo/)
* find an issue that looks interesting (https://starters.servo.org)
* leave a comment stating that you're working on it, and ask any questions necessary to make progress
* introduce yourself on IRC (https://wiki.mozilla.org/IRC in #servo) or on the mailing list (https://groups.google.com/forum/#!forum/mozilla.dev.servo)

====Automate web accessibility testing====
'''Mentor:''' [https://mozillians.org/en-US/u/mbrandt/ Matt Brandt] 
'''IRC:''' mbrandt

'''Project Description:'''
The internship entails researching how to test for web accessibility standards and then the application of that knowledge by reviewing several open source automated testing frameworks. Once they have chosen the framework that best suits our needs, that minimizes false positives, they will be responsible for codifying a suite of tests that are able to run within our Jenkins CI.

The project requires the intern to spend a short amount of time reading about web accessibility testing to help them gain domain knowledge. Prior experience with Javascript and Python is helpful but not required. Experience with an object oriented programing language is required, but can be gained by taking one of the many freely available online courses. An interest and aptitude in software engineering is encouraged.

As the intern pieces together a solution and implements the tests, they’ll help cleanup and update documentation. A willingness to reach out to members of the Firefox Test Engineering team as well as the Accessibility team for clarification will help round out the internship experience.

====Rust: Web Assembly showcase====
'''Mentor:''' [https://mozillians.org/en-US/u/brson/ Brian Anderson] 
'''IRC:''' brson

'''Project Description:'''
[https://www.rust-lang.org Rust] is a new systems programming language that is fast and memory
safe. It is growing quickly, is pleasant to contribute to, and is in
need of contributions in many areas!

In this project you will be developing a showcase application to
demonstrate Rust compiled to [http://webassembly.org/ WebAssembly], a new bytecode that runs
in the web browser. With WebAssembly, authors can write software that
runs on the web with near-native performance. It will unlock new
capabilities for the web, and Rust, with it's focus on low-level
performance, is one of the best-positioned languages to take advantage of WebAssembly.

This is a self-contained project where creativity and persistence will
lead to success. Design and implement a client-side web application,
written in Rust, that demonstrates the promise of running Rust
software on the web, by compiling to WebAssembly. Publish and blog
about the result.

This serves two important purposes: firstly, as a teaching tool, the
project demonstrates two bleeding-edge technologies used successfully
together. You will be at the forefront of this technology and people
will be looking to your early experience as they try it themselves.
Second, by writing a real application we will discover new bugs and
other problems with the stack. You will report these bugs to their
upstream projects, and even fix them yourself. This process of
validating our products by actually using them is called "dogfooding",
and it's an important part of product development.

At the end of this project you will have your own Rust-language web
application, will have new experience with Rust, WebAssembly,
JavaScript, and with collaboration in an active and friendly open
source community.

The project will run in 3 phases: in the first weeks you will
familiarize yourself with the tools: Rust, WebAssembly, emscripten,
and their development environment in and out of the web
browser. You'll work with your coach to identify a few key features
that the project will demonstrate and plan how to create them. The
second phase is where you will do planned implementation work.
Finally, with a few weeks left to spare, we will evaluate our
progress, decide how to present it most effectively, and then spend
the remaining time polishing and documenting it for release.

Good candidates will have moderate programming experience, either in
JavaScript or in a systems language like C, C++ or Rust. This work
will involve investigating and even debugging new compiler and web
browser features - much time will probably be spent examining the Rust
compiler's WebAssembly output and comparing it to expectations.
Interns will not be expected to fix bugs the Rust compiler itself on
their own, though they are certainly welcome to - their task is to
write an interesting web applications.

====Unsafe Code Linting Tool for Rust====
'''Mentor:''' [https://mozillians.org/en-US/u/nmatsakis/ Nicholas Matsakis] 
'''IRC:''' nmatsakis

'''Project Description''':
Rust is a new systems programming language that is fast and memory safe. It is growing quickly, is pleasant to contribute to, and is in need of contributions in many areas!

A crucial part of Rust's design is the ability for authors to use ""unsafe code"" to build up new abstractions and libraries. Unsafe code allows you to locally suspend some of the Rust type system rules, effectively giving you a lower-level language closer to C. The idea is that these lower-level details are encapsulated within a library that exports a safe interface. For example, the Rayon library exposes very convenient, simple primitives for writing threaded programs. If you stick to those primitives, your program will be free of data-races and other nasty parallel programming bugs. But internally the Rayon library makes use of traditional C-style threads to implement this abstraction.

At present, Rust doesn't give you very fine-grained tools for reasoning about unsafe code. Once you start writing an unsafely implemented library, it's entirely up to you to track whether a given pointer is safe to use and so forth. Just as when writing C code, this can easily go awry, particularly as code is updated. It could easily happen, for example, that an array index i is known to be in-bounds, and hence an unsafe array access (no bounds check) like vec[i] is safe. But as the program is updated, perhaps that assumption no longer holds -- now the array access could be out of bounds, leading to memory safety errors.

The goal with this internship is to develop a lint tool that would integrate with the rustc front-end to help improve the experience of writing unsafe code. This tool would allow unsafe code authors to write out and check more of their reasoning automatically: for example, they might document that why they believe that the variable i is in bounds (e.g., because it is compared against the length of the array, and the variable vec is not updated in the meantime). Then the tool can help check whether any of these assumptions stops being true (e.g., perhaps vec is changed to point to a different vector).

The project will involve both design and implementation. There is a general plan for how the linting tool should work, but part of the fun will be iterating on the tool once we try to put it to use and see how well it works. If all goes to plan, we can release the tool to the public.

Good candidates will have moderate programming experience in some language; experience with C, C++, or Rust specifically is not required. This work will primarily involve building a lint, which interfaces with the front-end of the Rust compiler, but will also involve learning a bit about the Rayon codebase (or some other suitable example of an unsafely implemented library).

====Push Notifications for Signin Confirmation====
'''Mentor:''' [https://mozillians.org/en-US/u/seanmonstar/ Sean McArthur] 
'''IRC:''' seanmonstar

'''Project Description:'''
You will be implementing a form of 2FA in Firefox Accounts. Once completed, if a user has multiple devices connected to their Firefox Account, they will be able to receive a push notification to one of their other devices asking for confirmation when trying to log in to their Firefox Account.

Skills required: Git, JavaScript (node and browser)

As part of your application please try to fix a ‘good first bug’ at: https://waffle.io/mozilla/fxa?label=good-first-bug

To get started with Firefox Accounts servers please visit: https://github.com/mozilla/fxa-local-dev

To learn more about Firefox Accounts project check out: https://fxa.readthedocs.io/en/latest/

====bugzilla.mozilla.org improvements====
'''Mentor:''' [https://mozillians.org/en-US/u/emceeaich/ Emma Humphries] 
'''IRC:''' emceeaich

'''Project Description:'''
1) [BMO RESKIN] Mozilla recently rebranded, and BMO doesn't match this re-branding at all. It would be nice to reskin it to look like the central Mozilla property it is.

Skills: CSS, HTML Templates, Perl

2) [BZ KANBAN] There is a kanban board that works using bugzilla APIs: https://github.com/leif81/bzkanban it would be very nice for (some teams, anyway) if this was integrated into BMO.

Skills: JavaScript, CSS, HTML, Perl

3) [METRICS GRAPHICS @ BMO] We have a very old reporting infrastructure that generates reports server-side and looks ugly. Meanwhile, another part of Mozilla has created the metrics graphics library. At minimum, replacing our existing reporting system with this would look spiffy.

====Implement UI Automated Tests for Treeherder using Selenium and Jasmine====
'''Mentor:''' [https://mozillians.org/en-US/u/camd/ Cameron Dawson] 
'''IRC:''' camd

'''Project Description:'''
Treeherder is a mission-critical product used by our core developers as well as our team of Sheriffs that help protect the quality of our code base. We have a very small number of automated tests for the UI. The rest must be done manually before each push to production.

This project would involve writing User Interface tests with Jasmine and Karma as well as Selenium. They would be executed automatically in Travis CI on each push to the master branch of the code-base and provide quick results on whether it is safe to push the new version of Treeherder to production.

====DevRel Website: Technical Content Creation/Management====
'''Mentor:''' [https://mozillians.org/en-US/u/havi/ Havi Hoffman] 
'''IRC:''' havi

'''Project Description:'''
This internship will be focused on content migration, content management, and multimedia content creation for a large complex website built in Drupal 8.

The Developer Relations team is building a site that speaks to developers, designers, and all those who build the Web. This project serves many goals:
*to update and modernize our blog, Mozilla Hacks (hacks.mozilla.org), and our Mozhacks YouTube channel
*to aggregate and share valuable content that is now spread across a host of websites and Mozilla wikis
*to raise awareness of the DevRel team and all the Mozillians who do outreach with people around the world who build the web
*to make it easy to discover all the ways Mozilla interacts with developers, designers, technologists.

In this role, you will help build out and maintain the new website over the course of our launch. Deliverables will be very tactical with hours focused on manual migration of content. In addition, there will be great opportunities to participate in content and asset creation for the new site.

The website will showcase key technologies being built by the Emerging Technologies group and evangelized by the DevRel team. The site will support many types of current and evergreen content: articles, videos, presentations, demos, events, and more, as well as profile pages for staff and contributors.

We think it's a great opportunity for someone seeking 'real-world' experience in:
*technical communications and media creation for the developer community
*in-depth, hands-on content management experience
*developing skills as an editor, technical communicator, and media creator
*working with a geo-distributed team of developer and designer advocates.

You’re a strong fit for this role if you have:
*basic experience and familiarity with online publishing in a variety of media formats
*working knowledge of HTML
*familiarity with WordPress, Drupal, or other content management systems
*experience with media creation tools are desirable (screencasts, video, codepens)
*Someone with skills to create demos in HTML, CSS, or to make videos is a plus.
*Javascript or Drupal site building skills an additional plus.

Please be detail-oriented, comfortable in written and spoken English. As a site editor/content manager, we’ll ask you to help others set up accounts and load their content.

====Upgrade ActiveData to use Elasticsearch v5+====
'''Mentor:''' [https://mozillians.org/en-US/u/ekyle/ Kyle Lahnakoski] 
'''IRC:''' ekyle

[https://github.com/klahnakoski/ActiveData/blob/dev/docs/Outreachy%20Proposal.md LIVE DOCUMENT WITH ANSWERS] 

'''Project Description:'''
''About ActiveData'' 
ActiveData is a publicly accessible data warehouse holding many billions of records, for some dozen+ datasets concerning Mozilla's testing infrastructure: This includes test results, job results, code coverage, and extracts from other systems. The ActiveData code itself is really only a stateless query translation layer; leaving the hard work of high speed filtering and aggregation to Elasticsearch.

''Background'' 
Elasticsearch is designed for text search, but can also serve as an extremely fast data warehouse. The speed comes from using [inverted indices](https://www.elastic.co/guide/en/elasticsearch/guide/current/inverted-index.html) to provide high performance data filtering and aggregation. Elasticsearch can index almost any JSON document, perform schema merging, and index all its properties, with almost no human intervention. By letting the machine manage the schema, we can query the JSON without transforming it

Elasticsearch does have a drawback: Its query language is designed for text search and is painful to use in a data warehouse context. Hence the need for ActiveData.

''Problem'' 
Elasticsearch 1.7.x was the last version that did a reasonable job of schema merging. Newer versions (2.0+) have disallowed schema merging, preventing ingestion of JSON documents that have a schema that conflicts with previous documents. We would like to use newer, faster, and more stable versions of Elasticsearch, but they can not handle varied data.

''Solution'' 
Build a translator will convert a variety of JSON formats into a single, strictly-typed, schema. The translator will use schema merging and property-renaming to perform a translation on documents before they go Elasticsearch.

''Benefits'' 
ElasticSearch's schema merging is great, but has always been incomplete: 1. It could not merge inner objects `{"a":{"b":1}}` with nested objects `{"a":[{"b":0}]}`, and 2. Merging numbers `{"a": 1}` with strings `{"b": "1"}` did not cause failure, but did leave the schema ambiguous, and made the queries clumsy. This upgrade will make ActiveData more flexible, improve service stability, and provide a step towards promoting this project to production.

''Required Skills'' 
Some particular experience will make this task easier (most important first):
* Python
* SQL and query languages
* Database normalization and functional dependencies
* Denormalization and data warehousing

''References'' 
1. Similar project for smaller data: [Mapping JSON to strict DB schema](https://github.com/klahnakoski/JSONQueryExpressionTests/blob/master/docs/GSOC%20Proposal.md) 
2. [ELT](https://en.wikipedia.org/wiki/Extract,_transform,_load) Links: [A](http://hexanika.com/why-shift-from-etl-to-elt/), [B](https://www.ironsidegroup.com/2015/03/01/etl-vs-elt-whats-the-big-difference/) 
3. [data cubes](https://en.wikipedia.org/wiki/OLAP_cube) 
4. [fact tables](https://en.wikipedia.org/wiki/Fact_table) in a [data warehouse](https://en.wikipedia.org/wiki/Data_warehouse). 
5. [MDX](https://en.wikipedia.org/wiki/MultiDimensional_eXpressions). 

====Upgrade Lightbeam====
'''Mentor:''' [Paul Theriault https://mozillians.org/en-US/u/pauljt/]
'''IRC:''' pauljt

'''Project Description:'''
The Mozilla Lightbeam extension is a key tool for Mozilla to educate the public about privacy and it’s due for an upgrade. It needs to be rewritten as a Web Extension and we will take this opportunity to investigate potential new features or integrations with Firefox. We are seeking a candidate with web development skills to work with the security engineering team to make this happen. We are looking for a front-end web developer who is passionate about privacy on the web. They should have an interest in design and visualization as the key part of this upgrade would be exploring how we can convey complex privacy & security concepts to the all Firefox users. Experience working with Web Extensions is a bonus but not required.

====Improve DevTools Network Monitor====
'''Mentor:''' [https://mozillians.org/en-US/u/odvarko/ Jan Odvarko] 
'''IRC:''' Honza

'''Project Description:'''
"Firefox Developer tools can be used to intercept all HTTP requests and responses executed by a page. This feature is represented by a Network panel that shows list of all HTTP requests and related details (like e.g. headers, formatted response body, timings, etc.)

In order to improve value of the panel we'd like to connect the existing UI to other backends performing HTTP activity (for example, Chrome browser or NodeJS) and adapt our current remote protocol (RDP) to a new environment."

==Outreachy Program Cohort: Round 13 (Dec 2016-March 2017)==

==== Improve the first-run experience of Firefox's location bar ====
Mentor: [https://mozillians.org/u/gijs/ Gijs Kruitbosch] 
Participant: Svetlana Orlik

Firefox's location bar currently uses your bookmarks, history and search engine to provide you with useful search results. When you're a new Firefox user, your bookmarks and history are empty, and so the initial experience can feel disorienting and unhelpful.

We'd like to provide users with an initial set of "autocompletion" results that provide domains that they are likely to navigate to. So that even when you're a new user, if you type in "face", we autocomplete to "facebook.com", and so on.

====Make WebExtension Development More Awesome====
Mentor: [https://mozillians.org/en-US/u/kumar/ Kumar McMillan] 
Participants: [https://mozillians.org/en-US/u/sj/ Shubheksha Jalan] and Elvina Valieva 
[https://medium.com/@shubheksha Shubhesksha's Blog] 
[https://saintsebastian.github.io/ Elvina's Blog] 

[https://developer.mozilla.org/en-US/Add-ons/WebExtensions WebExtensions] let anyone extend and customize their web browser, such as blocking ads on every website they visit. This is an exciting time for the API because it’s now possible to write a single extension that works in both Firefox, [https://developer.chrome.com/extensions Chrome], [https://dev.opera.com/extensions/ Opera], and soon IE. At Mozilla we provide several tools and resources to make developing extensions fun and easy but we’d like to make this development experience even better.

The participant will improve the productivity of WebExtension developers in the following ways. Most of these tasks involve changing the [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext web-ext] command line tool but others may involve writing documentation or example code.

* Utilize common web developer tools when building extensions.
** Craft examples that show how to use [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import ES6 imports] and other features that typically require code transpilation with [http://babeljs.io/ babel] or [http://rollupjs.org/ rollup]. [https://github.com/mdn/webextensions-examples/issues/97 More info].
* Automatically keep the web-ext tool up to date to avoid bugs.
** Alert the developer if their version of web-ext is out of date. [https://github.com/mozilla/web-ext/issues/142 More info].
* Offer extension “linting” in code editors
** Integrate web-ext's existing [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext#Checking_for_code_lint lint checking feature] into popular editors such as [https://atom.io/ Atom], [http://www.vim.org/ Vim], and [https://www.gnu.org/software/emacs/ Emacs]. [https://github.com/mozilla/web-ext/issues/539 More info].
* Add a new web-ext command that lays out a directory structure for an extension
** This command would automatically generate a manifest.json file and other common files to help the developer get started on a new extension. [https://github.com/mozilla/web-ext/issues/540 More info].
* Build a mock WebExtension API for use in automated tests
** Invent a JavaScript library that developers can use to execute tests for their extension without having to launch a web browser. [https://github.com/mozilla/web-ext/issues/497 More info].

====Build a Library of Inclusion Best Practices and Case Studies====
Mentors: [https://mozillians.org/en-US/u/lshapiro/ Larissa Shapiro] and [https://mozillians.org/en-US/u/lmn/ Lizz Noonan] 
Participants: Bee Padalkar, [https://mozillians.org/en-US/u/kristi.progri/ Kristi Progri], and Nasma Ahmed 
[http://networksfordata.wordpress.com/ Bee's Blog] 
[http://kristiprogri.com/ Kristi's Website] 
[http://www.nasmaahmed.ca Nasma's Website] 

This project is a community research project to identify and document examples of successful inclusive teams and communities within Mozilla, in order to amplify successes and highlight bright spots. The Outreachy participant will assess programs for suitability, and then interview participants, and then document case studies, referencing appropriate research and industry/community best practices. This is a great opportunity for a person interested in Diversity and Inclusion, Community Building, or User/Community research.

====Improving user experience of Firefox Accounts====
Mentor: [https://mozillians.org/en-US/u/vladikoff/ Vlad Filippov] 
Participant: Divya Biyani 
[http://divyabiyani.strikingly.com/ Divya's Website] 

There are several pending initiatives that are focused on improving the user experience of Firefox Sync and Firefox Accounts. As part of this Outreachy internship project, the participant will be involved in improving user interaction, running experiments, and measuring success of certain features.

Her software engineering skills will assist in the following:
* Developing new application improvements to reduce the number of user errors on password reset, password change, and sign up flows.
* Improving the verification rate and speed of new users signing up for Firefox Accounts.

To learn more about Firefox Accounts project check out: [https://fxa.readthedocs.io/en/latest/ fxa.readthedocs.io/en/latest/]

==== Add support for OpenAPI to Kinto ====

Mentors: [https://mozillians.org/en-US/u/ethan.glasser.camp/ Ethan Glasser-Camp] and [https://mozillians.org/en-US/u/natim/ Rémy Hubscher] 
Participants: Mansimar Kaur and Gabriela Surita 
[http://mansimar.com Mansimar's Website] 

Kinto has a fairly comprehensive set of documentation that describes its API. However, the cool new thing is OpenAPIs (formerly known as Swagger). Documenting our API using this specification would facilitate the implementation of client libraries in other languages as well as open the door to lots of other projects, including "interactive" documentation which has buttons that launch requests against a live server.

The Kinto team's participants will work on developing OpenAPI support in Kinto. The reservoir of tasks includes:
* Document the existing API by writing an OpenAPI specification. This will involve reading the existing documentation and experimenting with the Kinto server.
* Add runnable examples to the documentation. This will involve comparative analyses of available tools as well as working with our Sphinx-based documentation.
* Add an automated test that detects when the spec is out-of-date. This would involve working with our py.test-based unit testing suite.
* Write a mechanism to generate an OpenAPI specification from the Kinto source code. This would require writing Python code that hooks into the server code to identify APIs.
* Investigate the use of the OpenAPI specification to do fuzz-testing against the Kinto server. This would require an investigation of fuzzing tools and learning how to use them in a customized way.

==== Azure Blob Storage client library ====
Mentors: [https://mozillians.org/en-US/u/jhford/ John Ford] 
Participant: Elena Solomon 
[https://gabsurita.wordpress.com Elena's Blog]

The Taskcluster team at Mozilla builds an automation platform, similar in scope
to Buildbot and Jenkins. The project is built to support the continuous
integration testing of Mozilla projects like Firefox and Rust as well as
projects that Mozilla participates in like NSS. Taskcluster is a built
using distributed 'cloud' computing services where possible. We use the Azure
Storage framework for storing a lot of things. This library has Queue storage,
Table Storage. We have a wrapper that we like a lot called [https://www.npmjs.com/package/azure-entities 'azure-entities'] in NPM.

The goal of this project is to write a library to wrap the Azure Blob Storage
service. A preliminary effort has [https://github.com/taskcluster/aws-provisioner/blob/master/src/container.js already been done]. This project's participants will take this work and extend it to cover the majority of the
[https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-blobs/ Blob Storage API].
 

We specifically would like to have the following:
 
1. All Rest API endpoints [https://msdn.microsoft.com/library/dd135733.aspx implemented] using input validation to ensure that only valid data makes it to the API. [http://json-schema.org/ JSON Schema] is a great tool for this 
2. Ability to specify a JSON Schema to validate objects that we'll store or append to blobs, and also that we read out from them 
3. Ability to use [https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-shared-access-signature-part-1/ Shared Access Secrets (SAS)] as authentication 
4. Stretch goal of adding SAS for Blob storage to our [https://github.com/taskcluster/taskcluster-auth authorization service] 

==== Improve Template Logic for Taskcluster-Github ====

Mentor: [https://mozillians.org/en-US/u/bstack/ Brian Stack] and [https://mozillians.org/en-US/u/dustin/ Dustin Mitchell] 
Participant: [https://mozillians.org/en-US/u/ireneOwl/ Irene Storozhko] 

The Taskcluster team at Mozilla builds an automation platform, similar in scope
to Buildbot and Jenkins. The project is built to support the continuous
integration testing of Mozilla projects like Firefox and Rust as well as
projects that Mozilla participates in like NSS. Many of these projects
are developed on Github, and the Taskcluster-Github service acts as
the interface
between the two systems, creating tasks in response to Github events and
posting status updates back to Github. As other Mozillians have started using
Taskcluster-Github, they have identified some issues and missing features
in the service. With those fixed, more Mozillians can use TaskCluster
to improve the web.

This project involves addressing some of the more pressing user-identified issues with TaskCluster. 

It is a collection of smaller projects: 
* Add support for creating tasks in response to new Git tags. This would allow users to run "release" tasks when they push a new version tag, for example. 
* Make the repository enrollment process "self-serve". Currently, if a team wants to use Taskcluster-Github, they must ask a person on the Taskcluster team to set that up for them. That can be slow and discourages experimentation. With this project completed, users can set up a new repository with a few clicks. 
* Add "build shields", similar to http://shields.io/ that will show the latest status of a Taskcluster-Github build or test run.

====Webcompat.com Content & Participation Experience Researcher====
Mentor: [https://mozillians.org/en-US/u/astevenson/ Adam Stevenson] 
Participant: Mesha Lockett 
[http://meshalockett.com/ Mesha's website] 

Mozilla's Web Compatibility team builds and maintains a website called webcompat.com that allows individuals to easily report site compatibility issues - and to allow us to better understand the larger picture of compatibility issues affecting Firefox users on the web.

In this Outreachy project, the participant will commit to one or more of the following projects to help us improve our on-boarding process for new contributors:

*Review & update web compatibility documentation
*Identify and promote good features and bugs that need a contributor on social networks
*Make creative assets to be used on webcompat.com
*Review the user experience for contributors to webcompat.com
*Help redesign the contributors page on webcompat.com
*Create screencasts or scripts for screencasts that explain how to contribute to webcompat.com
*Assess the current workflow and suggest areas for improvement

====Make Treeherder faster with ReactJS====

Mentor: [https://mozillians.org/en-US/u/camd/ Cameron Dawson] 
Participant: Casey Williams

Treeherder is growing. More people are using it every day. And the amount of data it displays is also growing. So we need to expand its ability to scale to more and more data. Treeherder is primarily written in AngularJS on the front-end. However, we display thousands of small objects on the main landing page. Using Angular’s ng-repeat for this proved unacceptably slow. It was converted to using JQuery and raw JavaScript DOM manipulation which has been acceptably fast for a while, but is harder to maintain. ReactJS has been used in other parts of the product to significantly improve performance and is easier to read and edit. The participant will convert the existing job matrix rendering to use ReactJS.

= For Future Applicants =
* Next Outreachy round is Winter 2016-17. Keep in touch by reading here or on gnome.org/outreachy to learn application deadlines.

== Application Process ==
Applicants and mentors, please review the [https://wiki.gnome.org/Outreachy#Program_Details Outreachy Eligibility and Application Information page] to learn more about applying for Outreachy.

First steps for applicants to Mozilla:
# Set up [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Getting_Started_with_IRC IRC].
# Set up a [https://bugzilla.mozilla.org Bugzilla] account and a [https://mozillians.org Mozillians] profile. Please include your IRC nickname in both of these accounts so mentors can work with you more easily. For example, Eve Smith would set their Bugzilla name to "Eve Smith (:esmith)", where esmith is their IRC nick.
# Please look at the projects below, consider your options, and chat with Mozilla mentors on IRC. You need to make a small contribution to the area you wish to apply for.
#* To chat with Mozilla mentors, join the #outreachy channel on '''irc.mozilla.org'''.
#* To ask general questions about Outreachy or the application process, you can also try #outreachy IRC channel on irc.gnome.org.

==Projects to Apply for==
Outreachy Round 13 applications have closed, but we encourage you to apply to the next round of projects in April. 

Got Questions? Ask:
* Outreachy Coordinator: [https://mozillians.org/en-US/u/lmn/ Lizz Noonan]
* IRC: #outreachy

=Past Outreachy/OPW internships=

{{#subpages:}}

==Complete List of Participants==
===ROUND 12===
====Ana Ribero====
* Mentor: [https://mozillians.org/en-US/u/davehunt/ Dave Hunt]
* Project: Enhancements to Python testing tool plugin for generation of HTML reports
* [https://mozillians.org/en-US/u/anaribeiro/ Mozillians Profile]
* [http://outreachy.anaplusplus.com/ Participant Blog]

====Rakhi Sharma====
* Mentor: [https://mozillians.org/en-US/u/Gijs/ Gijs Kruitbosch]
* Project: Make Firefox look great on desktop!
* [https://mozillians.org/en-US/u/Rakhi/ Mozillians Profile]
* [http://rakhish.wordpress.com/ Participant Blog]

====Manel Rhaiem====
* Mentors: [https://mozillians.org/en-US/u/kglazko/ Kate Glazko] and [https://mozillians.org/en-US/u/marcia/ Marcia Knous]
* Project: Project SmartHome prototyping
* [https://mozillians.org/en-US/u/Mermi/ Mozillians Profile]
* [mermi.xyz Participant Blog]

====Deepthi Venkitaramanan====
* Mentor: [https://mozillians.org/en-US/u/miketaylr/ Mike Taylor]
* Project: Webcompat.com Web Application Engineer
* [https://mozillians.org/en-US/u/venkid/ Mozillians Profile]
* [http://venkid.com/portfolio.html#Outreachy Participant Blog]

====Benjamin "Benny" Forehand, Jr.====
* Mentor: John Dorlus <jdorlus@mozilla.com>, Silne30 on IRC
* Project: Convert Mozmill tests to Marionette
* [https://mozillians.org/en-US/u/bennyjr35/ Mozillians Profile]
* [https://www.bennyjr.xyz/blog and https://benjaminfjr.blogspot.com/ Participant Blog]

====Ipsha Bhidonia====
* Mentor: [https://mozillians.org/en-US/u/natim/ Remy Hubscher]
* Project: Realtime Push Notifications for Kinto
* [https://mozillians.org/en-US/u/ipsha21/ Mozillians Profile]
* [https://ipsha218.wordpress.com/feed/ Participant Blog]

====Anjana Vakil====
* Mentor: [https://mozillians.org/en-US/u/maja_zf/ Maja Frydrychowicz]
* Participant: Test-driven Refactoring of Marionette's Python Test Runner
* [https://mozillians.org/en-US/u/vakila/ Mozillians Profile]

====Rutuja Surve====
* Mentor: [https://mozillians.org/en-US/u/mconley/ Mike Conley]
* Project: Content Process Management Tool
* [https://mozillians.org/en-US/u/Rutuja/ Mozillians Profile]
* [https://rutujasurveblog.wordpress.com/2016/05/17/outreachy-2016-my-first-post/ Participant Blog]

====Andrea Del Rio Lazo====
* Mentors: [https://mozillians.org/en-US/u/wcosta/ Wander Lairson Costa] and [https://mozillians.org/en-US/u/dustin/ Dustin J. Mitchell] 
* Project: Taskcluster tools UI/UX improvements
* [https://mozillians.org/en-US/u/andreadelrio/ Mozillians Profile]

====Kristel Teng====
* Mentor: [https://mozillians.org/en-US/u/jonasfj/ Jonas Finnemann Jensen] and [mailto:bstack@mozilla.com Brian Stack] 
* Project: Automation of Taskcluster Documentation
* [https://mozillians.org/en-US/u/kt/ Mozillians Profile]

====Katie Broida====
* Mentor: [https://mozillians.org/en-US/u/jaws/ Jared Wein]
* Project: Fixing some papercuts in the Firefox desktop user interface
* [https://mozillians.org/en-US/u/kbroida/ Mozillians Profile]
* [http://blog.katiebroida.com/ Participant Blog]

====Decky Coss====
* Mentor: [https://mozillians.org/en-US/u/ehsan/ Ehsan Akhgari]
* Project: Web Platform Test Crime Scene Investigation
* [https://mozillians.org/en-US/u/deckycoss/ Mozillians Profile]
* [http://cosstropolis.com/blog/ Participant Blog]

====Jen Kagan====
* Mentors: [https://mozillians.org/en-US/u/6a68/ Jared Hirsch] (_6a68 on IRC) and [https://mozillians.org/en-US/u/djustice/ Dave Justice] (JSON_voorhees on IRC) 
* Project: Prototype new Firefox features with the Test Pilot team
* [https://mozillians.org/en-US/u/kaganjd/ Mozillians Profile]

===ROUND 11===

==== Lauren Conrad ====

Participant: [https://mozillians.org/en-US/u/laurenconrad1993/ Lauren Conrad]

Based in: Rye Brook, New York USA. (For anyone who doesn't know, that's a suburb right outside New York City!)

Mentor: Joni Savage

"I am thrilled to be working for such a well known company and to be translating my writing skills into the tech world."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#SUMO_-_Build_a_tutorial_or_training_tool_for_new_technical_writers SUMO - Build a tutorial or training tool for new technical writers]

Project blog: [http://www.laureneconrad.com www.laureneconrad.com]

==== Roxana Ilie ====
Participant: [https://mozillians.org/en-US/u/roxana.ilie23/ Roxana Ilie]

Based in: Bucharest, Romania

Mentor: [https://mozillians.org/en-US/u/pmcmanus/ Patrick McManus]

"I am very excited to be joining the Mozilla Outreach Program because after enjoying so much using the browser, I will have the opportunity to give something back and use my knowledge in order to help the community to improve Mozilla Firefox."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Battery_Friendly_Platform_Networking_Deadline_Scheduler Battery Friendly Platform Networking Deadline Scheduler]

==== Richa Rupela ====

Participant: Richa Rupela

Based in: Bikaner, Rajasthan, India

Mentor: [https://mozillians.org/en-US/u/annevk/ Anne van Kesteren]

"Super excited to work on Whatwg project, mentored by Anne van Kesteren. Mozilla Outreach program has given me a great opportunity of working with a such a elite community. Looking forward to an awesome winter where I will work on the HTML standards!"

Richa's project blog: https://richarupela.wordpress.com/

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 Contribute to the HTML Standard!]

==== Shweta Oak ====
Based in: Mumbai, India

Mentor: [https://mozillians.org/en-US/u/alexis/ Alexis Metaireau]

"I am extremely excited to be a part of an organization that is so instrumental in the development of the open web and get a chance to make contributions that enrich the lives of people."

[https://wiki.mozilla.org/Outreachy/2016/December_to_March#Kinto_.E2.80.94_Make_instances_discoverable Project: Kinto — Make instances discoverable]

==== Jullie Utsch ====
Participant: [https://mozillians.org/en-US/u/jullieutsch/ Jullie Utsch]

Based in: Belo Horizonte - MG Brazil

Mentor: [https://mozillians.org/en-US/u/ilana/ Ilana Segall]

“What makes me excited about Outreachy: Being part of a great community, sharing with incredible people and taking part in making the tech industry a little more diverse. :)”

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data_.5Bno_longer_taking_applications.5D Visual Design with Research Data]

==== Cynthia Anyango ====
Participant: [https://mozillians.org/en-US/u/acynthiaanyango/ Cynthia Anyango]
Based in: Nairobi , Kenya

Mentor: [https://mozillians.org/en-US/u/kthiessen/ Karl Thiessen]

"I am excited to join Mozilla for the outreach program especially the project I am attached to because I get to contribute to open source Mozilla services that make lives better"

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Enumerate_.28and_Dockerize.29_the_tests.21_.28Quality_Assurance Enumerate (and Dockerize) the tests! (Quality Assurance)]

==== Nikki Bee ====
Participant: [https://mozillians.org/en-US/u/nikkicubed/ Nikki Bee]

Based in: Alberta, Canada

Mentor: [https://mozillians.org/en-US/u/jdm/ Josh Matthews]

"I'm excited at the chance to learn Rust and contribute to a major FOSS project, especially for an organization that has been as welcoming as Mozilla."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard Servo: Complete implementation of Fetch standard]

==== My Lê ====
Based in: Paris - France

Mentor: [https://mozillians.org/en-US/u/ricardo/ Ricardo Vazquez]

"Proud to be part of Mozilla Outreachy Program, sharing knowledge and contributing to the Open Web."

Project: [https://wiki.mozilla.org/Outreachy/2016/December_to_March#Open_Source_Designer.2C_Mozilla_Foundation Open Source Designer, Mozilla Foundation]

===ROUND 10===

https://wiki.gnome.org/Outreachy/2015/MayAugust#Participating_Organizations

Thalia Chan (Tchanders), London, UK - Socorro crash statistics front-end development - Adrian Gaudebert

Alice Duarte Scarpa (adusca), Rio de Janeiro, Brazil - Integrate the ability to arbitrarily retrigger jobs into functional tools & production quality code - Armen Zambrano Gasparnian

Gloria Dwomoh (blossomica), Piraeus, Greece - Air Mozilla web design and development - Peter Bengtsson

===ROUND 9===

https://wiki.gnome.org/OutreachProgramForWomen/2014/DecemberMarch#Participating_Organizations

Lisa Hewus Fresh Portland, OR, USA - Air Mozilla Web Design and Development - Peter Bengtsson

Tessy Joseph (tessy), Kerala, India - One and Done - Rebecca Billings

Barbara Miller (galgeek), Portland, OR, USA - QA/Automation - Henrik Skupin

Adam Okoye (aokoye), Portland, OR, USA - SUMO/Input Web Design and Development - Will Kahn-Greene

===ROUND 8===

https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#Participating_Organizations

Francesca Ciceri (MadameZou), Massa, Italy - Bug wrangling - Liz Henry

Joelle Fleurantin (Queeniebee), New York, NY, USA - Maintaining the Gateway: Improving Mozilla Wiki through updating Information Architecture and Theme - Christie Koehler

Maja Frydrychowicz (maja_zf), Montreal, Quebec, Canada - Django development for One and Done - Liz Henry

Sara Mansouri (sara_mansouri), Saskatoon, Saskatchewan, Canada - Redevelopment of badges.mozilla.org and other contributor gamification infrastructure - Larissa Shapiro

===ROUND 7===

https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Participating_Organizations

Isabelle Carter (ibnc), Springfield, MO, USA - Servo - Lars Bergstrom

Jennie Rose Halperin (jennierose), Carrboro, NC, USA - Community building - Larissa Shapiro

Jennifer "Nif" Ward (nif), Oberlin, OH, USA - Rust - Tim Chevalier

Sabina Brown (binab), Santa Cruz, CA, USA - SUMO (Support.Mozilla.org) community building - Ibai Garcia

===ROUND 6===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JuneSeptember#Participating_Organizations

coordinators: Selena Deckelmann and Liz Henry

Gabriela Salvador Thumé (gabithume), São Carlos, São Paulo, Brazil - Socorro - Selena Deckelmann

Tiziana Sellitto (tiziana), Salerno, Italy - Bug wrangling - Liz Henry

===ROUND 5===

https://wiki.gnome.org/OutreachProgramForWomen/2013/JanuaryApril#Participating_Organizations

Lianne Lee (llmelon), Sydney, Australia - Release metrics dashboard - Lukas Blakk

Community:SummerOfCode17

2017-03-02T16:11:52Z

Klahnakoski: /* Automation & Tools */ add email

This is Mozilla's list of green-lit project proposals for the 2017 Google Summer of Code.

Are you a student looking to apply to GSoC with Mozilla? You're in the right place. This page lists all the confirmed [[SummerOfCode|Google Summer of Code]] projects. New suggestions can be made on [[Community:SummerOfCode17:Brainstorming|the Brainstorming page]]. Do not edit this page yourself; contact Mike Hoye or Florian for edits.

If you're interested in participating in Mozilla's GSoC program, you can choose from the list below, '''but you do not have to'''. You can submit a proposal for your own idea. You should look at the [[Community:SummerOfCode17:Brainstorming|guidelines]], though, and discuss your ideas or application in the #introduction channel on IRC.Mozilla.org. This is important, as GSoC projects '''must have''' a supporting member of the Mozilla community to evaluate and mentor them, named in the application.

===Application Advice===

You should do the following:

* Talk to the mentor. Contact details are on this page; if all you have is a nickname, reach out to them on IRC.
* Read the [https://flossmanuals.net/GSoCStudentGuide/ GSoC Student Guide] and follow its advice.
* Read [http://blog.gerv.net/2006/05/how_not_to_apply_for_summer_of/ How Not To Apply For Summer Of Code] and avoid doing the things listed there.
* Read our examples of good applications: [[SummerOfCode/SampleApplications/1|1]], [[SummerOfCode/SampleApplications/2|2]], [[SummerOfCode/SampleApplications/3|3]].
* Apply on [https://summerofcode.withgoogle.com/ the GSoC site] (note that we have an [[SummerOfCode/ApplicationTemplate|application template]]).
* It is entirely acceptable to apply for 2 or 3 projects, if more than one catches your eye; if the applications are high quality, that can improve your chances. Applying to more than that will seem like spam.

Questions about individual projects are best addressed to the potential mentor of that project. These should be listed in the table below. If you want to contact a mentor and contact details are not here, ask people in the #introduction channel on IRC: irc://irc.mozilla.org/#introduction. If you have questions of any other sort, send mail to [mailto:mhoye@mozilla.com Mike Hoye]. He will try and respond promptly and direct your questions to the right person.

===Project List===

[[SummerOfCode|Here are the ideas lists from previous years]].

Proposals can be in almost any part of the Mozilla project - don't be fooled by the "Code" in "Summer of Code". If there is no category below for your part of Mozilla, add one!

== Mozilla Platform (Gecko) ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| TaskCluster JSON Parameterization
| Build a powerful JSON parameterization system and use it everywhere
| JavaScript, Python
| :dustin
| :dustin
| The json-e language supports complex transformations of JSON data. The project involves completing the specification, implementation (in two languages), and documentation of this language, then using it to support Gecko action and decision task and users of taskcluster-github and taskcluster-hooks. Success here means that the language is complete and in active use in at least one of the listed contexts.
|-
| Livelog Proxy
| Write a server that privileged-clients can open a HTTPS connection to in-order to expose a webhook that http-clients can call.
When normal http-clients access the exposed webhooks the connection will be reverse proxied to the
privileged-clients over their out-going connection.
| golang, github, http, web sockets, node.js
| :jonasfj
| :jonasfj
| This is like to ngrok and localtunnel.me, read up on those. For performance reasons server should be written in golang, with client libraries in golang and node.js.
|
|}

== Firefox ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| about:telemetry redesign
| about:telemetry is present on all builds of Firefox as a way for users to view the data being stored and sent via Telemetry. It was built before Firefox had multi-process Telemetry and without a clear design. This has resulted in a confusing HTML UI and barely-comprehensible JS.
| webtech (HTML+CSS+JS) and Design
| :chutten
| chutten@mozilla.com
| [[Telemetry/GSoC17:AboutTelemetry|Some information]]
|-
| Boost Session Restore performance
| Session (Re)store is important as a key feature of Firefox. Many people rely on it to re-open a tab from the past or recover from an unfortunate power outage. But making it blazing fast has not been our primary focus, until now. Your goal will be to help us make restoring any session snappy and blazing fast. Expect to learn a lot about the Firefox internals and interact with many core engineers during the SoC course.
| JavaScript
| :mikedeboer
| :mikedeboer, :dao
|
|}

== Firefox for Android ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| Implement WebExtension APIs
| [https://developer.mozilla.org/en-US/Add-ons/WebExtensions WebExtensions] are a cross-browser system for developing browser add-ons. [http://arewewebextensionsyet.com/ Not all APIs are supported] by Firefox for Android yet.
The goal of this project is to:
* Implement some of the missing APIs ([https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/contextMenus contextMenus], [https://developer.chrome.com/extensions/browsingData browsingData], [identity?], [proxy?])
* Add automated test for those APIs
* Improve the tooling for building WebExtensions for Firefox for Android.
| Java, JavaScript, Android
| [https://mozillians.org/en-US/u/sebastian.kaspari/ :sebastian]
| [https://mozillians.org/en-US/u/sebastian.kaspari/ :sebastian]
|}

== Automation & Tools ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
! JS static analysis
! Bring some static analysis in our Firefox Javascript code
! Javascript experience, FLOW(?)
! [mailto:s@mozilla.com Sylvestre]
! [mailto:s@mozilla.com Sylvestre]
! This project aims to evaluate and integrate more static analysis for Javascript code into some key sections of the Firefox code. We will focus on deploying [https://github.com/facebook/flow FLOW] on some part of the code as a proof of concept. Depending on the results, this will be extended to more components and/or integration in the developer workflow.
|-
! C++ static analysis
! Add new checkers specific to our base code
! Strong C++ experience, clang
! [mailto:s@mozilla.com Sylvestre]
! [mailto:andi@mozilla.com Andi]
! In order to tackle issues during the development phase, Mozilla wrote a [https://hg.mozilla.org/mozilla-central/file/tip/build/clang-plugin bunch of static analyzers checkers] based on [http://clang.llvm.org/extra/clang-tidy/ clang-tidy]. In this project, we will focus on writing more checkers (either generic to C/C++ or specific to Gecko programming patterns).
|-
! JSON in Sqlite
! Query JSON Documents stored in Sqlite
! Database, SQL, Python
! [mailto:klahnakoski@mozilla.com Kyle Lahnakoski]
! [mailto:klahnakoski@mozilla.com Kyle Lahnakoski]
! [https://github.com/klahnakoski/JSONQueryExpressionTests/blob/master/docs/GSOC%20Proposal.md Details]
|-
! View details of performance test results
! At the moment, Perfherder provides summarized views of results of Talos tests and others, but not the individual test results, athough the supporting data exists. This project will be about creating an easy-to-use web interface for visualizing this data that integrates well with the existing Perfherder views
! HTML, CSS, JS, AngularJS
! Will Lachance (:wlach)
! Will Lachance (:wlach), Robert Wood (:rwood)
! [https://wiki.mozilla.org/Auto-tools/Projects/Perfherder Perfherder wiki] / [https://bugzilla.mozilla.org/show_bug.cgi?id=1164891 bug] (don't be fooled by the fact that there is just one bug, there is easily enough work here to fill a gsoc project)
|-
! Regression localization from stack traces
! Tool to blame a patch for causing a newly introduced crash.
! C++, Python
! [mailto:marco@mozilla.com Marco]
! [mailto:marco@mozilla.com Marco]
! The project would involve creating a tool that analyzes a set of stack traces, performing the intersection with the Firefox call graph (which can be generated using Clang) and a set of recently committed patches.
|-
! Improvements for crash clustering
! Build a tool to improve crash clustering, currently based on the top method of the stack trace.
! Python, C++
! [mailto:marco@mozilla.com Marco]
! [mailto:marco@mozilla.com Marco]
! The project would involve finalizing https://github.com/marco-c/crashsimilarity; testing it more thoroughly; putting it in production.
|}

== Mozilla Developer Network ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| MDN Documentation Tester WebExtension
| Rewrite the [https://github.com/Elchi3/mdn-doc-tests MDN doc tester add-on] as a (well-tested, modern, documented) WebExtension that runs in Firefox, Chrome, Opera, and possibly Edge. Ideally reach feature parity with the existing Add-on SDK add-on and if time allows work on new test ideas that run against the MDN documentation.
| Add-On/WebExtension experience (JavaScript, HTML, CSS)
| Florian Scholz
| Florian Scholz
|}

== Release Engineering ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| Improve Balrog's Admin API
| Make Balrog's Admin API simpler and easier for clients to work with by moving to a [http://swagger.io/ Swagger]-based approach.
| python,rest apis
| Ben Hearsum (bhearsum@mozilla.com)
| Ben Hearsum (bhearsum@mozilla.com)
|}

== Rust ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
! Rust + WebAssembly showcase
! Rust and WebAssembly are going to be a great pair. Design and implement a simple and attractive web application, in Rust, that demonstrates the power of Rust on the web. Make fixes to upstream projects as necessary. Write a blog post about it.
! Rust, web development
! brson
! brson, badboy
! cc https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and-emscripten/7627. Full proposal: https://gist.github.com/brson/c936d0f5e5ec8c806a41e23e87455665#file-rust-proj-1-md
|-
! Rust dashboard updates
! Update rusty-dash.com to include additional metrics important to the project. This tool is vital to the day-to-day management of Rust, but it needs some dedicated attention to fulfill its promise.
! Rust
! brson
! brson, aturon?, dikaiosune?
! Follow on work to https://internals.rust-lang.org/t/the-rust-project-needs-much-better-visibility-into-important-metrics/3367
|-
! Rust reproducible builds
! Make the Rust build process produce the identical binaries when run with identical configurations. This improves the security of the Rust ecosystem by allowing others to
double-check the official Rust builds
! Rust, compilers, systems programming
! brson
! brson, mw, Manishearth
! https://internals.rust-lang.org/t/verifying-rustc-releases-with-reproducible-builds/4502. Full proposal: https://gist.github.com/brson/c936d0f5e5ec8c806a41e23e87455665#file-rust-proj-2-md
|-
! Abstract the Rust standard library
! The Rust standard library is very portable, but can be very, very portable. Refactor the
standard library to pull out a platform abstraction layer.
! Moderate Rust experience
! brson
! brson
! https://internals.rust-lang.org/t/refactoring-std-for-ultimate-portability/4301
|-
! Rust cross-platform showcase project
! Rust is very portable. Create a single showcase demo project that compiles for Windows, OS X, Linux, Android, iOS, wasm, and microcontrollers. Use real crates to accomplish some real task. Set up CI for all platforms on Travis. To be used as a teaching tool and for regression testing. Write a blog post.
! Moderate Rust experience
! brson
! brson
!
|-
! rustc micro-optimization bonanza
! Just go hog wild finding microoptimizations in rustc. Write a blog post bragging about it.
! Performance optimization
! brson
! brson, nnethercote?
!
|-
! Rust-specific benchmark suite
! Today Rust uses perf.rust-lang.org to track _compile time_ performance, but nothing to track _runtime_ performance. Work with the Rust developers to create a benchmark suite specific to Rust.
! Programming
! brson
! brson
!
|-
! Rust crate semver compatibility tool
! Rust libraries follow the semver spec for indicating API compatibility, but conformance to semver is not enforced in any way - it is up to crate authors to guarantee their crates can be upgraded correctly. With Rust's strong type system it should be possible to mechanically check whether crates
are obeying semver. This would be a huge boon to the stability of the Rust ecosystem.
! Static analysis
! brson
! brson, badboy
! https://users.rust-lang.org/t/warnings-for-breaking-semver/1415 https://users.rust-lang.org/t/signature-based-api-comparison/2377 . Full proposal: https://gist.github.com/brson/c936d0f5e5ec8c806a41e23e87455665#file-rust-proj-3-md
|-
! Reconstruct the Rust bootstrap chain
! Rust is a self-hosted compiler, originally bootstrapped from OCaml, then self-bootstrapped several hundred times over the years. Today there is only one Rust 'lineage' of any note, the official compiler, but with compilers diversity of implementation is a security issue. If another party could replicate the
Rust compiler it would provide assurance that the official isn't compromised by, or can recover from, a "trusting trust" attack. Although the historical information needed to rebootstrap Rust is mostly complete, it is not trivial to do. Construct a script that can reconstruct the modern Rust compiler from the original OCaml implementation, run it to completion, write a blog post.
! Scripting, build systems
! brson
! acrichto
!
|-
|}

== Servo ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| Off-main thread HTML parsing
| [https://github.com/servo/servo/wiki/Off-main-thread-HTML-parsing-project Project page]
| Enthusiasm to learn Rust, comfortable reading/writing JavaScript
| [https://mozillians.org/en-US/u/jdm/ jdm]
| Anthony Ramine (nox)
|
|-
| Extend ServiceWorker implementation
| [https://github.com/servo/servo/wiki/More-ServiceWorker-support-project Project page]
| Enthusiasm to learn Rust, comfortable reading/writing JavaScript
| [https://mozillians.org/en-US/u/jdm/ jdm]
| [https://mozillians.org/en-US/u/jdm/ jdm]
|
|}

== Security Engineering ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| Tor Experiment
| Create a an experimental extension that bundles and launches Tor. Benchmark and report the amount of data transferred, time-to-first-byte, bandwidth differentials.
| Add-On creation experience, Programming in C/Javascript.
| Tom Ritter
| Tom Ritter
|-
| StopTrackware.org
| Create a clearinghouse of trackware lists like StopBadware.org, by creating a Track-the-trackers add-on that uses data [http://www2016.net/proceedings/proceedings/p121.pdf "safeness" approach like Cliqz]
| Add-On creation experience (JavaScript, HTML, CSS, Networking), Cloud Service experience (python or node.js)
| Luke Crouch
| Luke Crouch
|
|}

== Localization ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| Design screenshot-based localization interface in [https://pontoon.mozilla.org/ Pontoon]
| We'd like to explore the feasibility of screenshot-based localization process in [https://pontoon.mozilla.org/ Pontoon] - Mozilla's translation tool. To provide more translation context, each string will be accompanied by a screenshot showing how the string is used in the application. Additionally, localizers will have the ability to navigate and filter strings by screenshots, as well as preview their translations in the localized screenshots.
| Web standards and Design. Django is a plus.
| [[User:Mathjazz|:mathjazz]]
| [[User:Mathjazz|:mathjazz]]
|
|}

== Security Assurance ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|
TLS 1.3 scanning in Mozilla TLS Observatory
|
[https://github.com/mozilla/tls-observatory Mozilla TLS Observatory] is a hosted service that provides hindsight and compliance checking on the configuration of HTTPS servers. The goal of this project is to improve the service to support scanning TLS 1.3 enabled endpoints, either by improving the [https://github.com/mozilla/cipherscan existing scanner] or writing an entirely new scanner.
|
Programming skills in C, Bash and Go. Strong understanding of TLS and micro-services architectures.
|
Julien Vehent
|
Julien Vehent
|
None
|}

== Mozilla Science Lab ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| science.mozilla.org phase 2
| Start phase 2 of the Mozilla Science Lab website by implementing
* [https://github.com/mozilla/science.mozilla.org/issues/135 github authentication],
* [https://github.com/mozilla/science.mozilla.org/issues/311 members homepage],
* [https://github.com/mozilla/science.mozilla.org/issues/536 improve blog post readability], and add the
* [https://github.com/mozilla/science.mozilla.org/issues/518 ability to join projects]
| js, html, css, react, django, python
| [https://mozillians.org/en-US/u/Abby/ abbycabs]
| [https://mozillians.org/en-US/u/alanmoo/ alanmoo]
| Detailed list and breakdown of all phase 2 work (only the tasks mentioned in details are expected to be completed by the student):
* Phase 2.1 https://github.com/mozilla/science.mozilla.org/milestone/11
* Phase 2.2 https://github.com/mozilla/science.mozilla.org/milestone/12
|-
| Paper Badger - badgr migration & publisher integration
| * Issuing badges to credit authors for their work on academic papers.
* In the final steps of our badgekit to Badgr migration, add tests to make sure we have feature parity and make the switch to Badgr in production.
* Implement a [https://github.com/mozillascience/PaperBadger/issues/160 journal submission system integration] with paper badger. This way, journals won't have to manually enter new badges in our system.
| js, Badgr, APIs, authentication, node.js, react
| [https://mozillians.org/en-US/u/Abby/ abbycabs]
| [https://mozillians.org/en-US/u/Abby/ abbycabs]
| github: https://github.com/mozillascience/paperbadger
|-
| Study Group participation visualization
| [https://github.com/mozillascience/studyGroup study groups] meet all over the world, running regular events share skills, co-work and create community around open science. Right now there's no easy way to see all the study group events.
* Write a script to collect data for all study group events happening world wide. Each study group is a [https://github.com/mozillascience/studyGroup fork of this template repo]. Each event is an issue in the repo ([https://github.com/UofTCoders/Events/issues example of events as issues]). [https://github.com/mozillascience/studyGroup/blob/gh-pages/scripts/updateCalendar.py here is a script] that collects all events for a specific repo. Please update this to collect data from all forks.
* Visualize this data in a way that shows study group activity all around the world! viz: calendar, map
| js, html, css, python (or another scripting language), data visualization
| [https://mozillians.org/en-US/u/zannah/ Zannah]
| [https://mozillians.org/en-US/u/aurelia/ Aurelia]
| main study group repo: https://github.com/mozillascience/studyGroup
|}

== Thimble ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| Address stability issues within Thimble
| Main task: Get Thimble to write directly to AWS instead of writing to a database first.
| js, html, css
| [https://mozillians.org/en-US/u/gideon/ gideon]
| [https://mozillians.org/en-US/u/gideon/ gideon]
| Full list of issues affecting thimble's stability: https://github.com/mozilla/thimble.mozilla.org/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3A%22good%20first%20bug%22%20-label%3A%22assigned%20to%20contributor%22
|-
| Integrating VR capabilities into Thimble
| Goal: Thimble makes it easy to create multi user VR experiences, allowing the whole classroom to take virtual field trips through student projects.
This is made possible by doing any of these:
* Integration of the A-frame visual inspector, which gives the user lots of control over an object properties in a custom UI
* Custom Quick-Edit UI for different types of objects
* Develop large, visual menu of 3D objects make it easy to build interesting scenes quickly
* A wide range of starter projects
| js, html, css
| [https://mozillians.org/en-US/u/gideon/ gideon]
| [https://mozillians.org/en-US/u/gideon/ gideon]
| This work would be done in parallel with work done by [https://cdot.senecacollege.ca/ CDOT] on making Thimble a VR experience building tool
thimble repo: https://github.com/mozilla/thimble.mozilla.org
|-
| Thimble and Remote Mentorship
| Goal: Use together.js to enable a multi-user environment on Thimble that is tailored to work as a virtual teaching environment for HTML/CSS/JS
Details:
* Fixing issues in together.js to make it functional
* working on ways to sync state between Thimble's editor and the remote Thimble editor(s
* Syncing filesystems across Thimble editors with WebRTC
| js, html, css
| [https://mozillians.org/en-US/u/gideon/ gideon]
| [https://mozillians.org/en-US/u/gideon/ gideon]
| thimble repo: https://github.com/mozilla/thimble.mozilla.org
|}

== Bugzilla ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|-
| Bugzilla Reskin
| Goal: Mozilla recently rebranded, and BMO doesn't match this re-branding at all.
Details:
* This work would be 80% CSS, 15% templating, and 5% perl.
| js, html, css
| :dylan
| [mailto:dylan@mozilla.com dylan]
|
|}

EngineeringProductivity/Projects/CodeCoverage

2017-03-02T01:05:31Z

Klahnakoski: /* Code Coverage */ add note about updates

=Code Coverage=

March 1st, 2017 - This project is active, but this page is stale. Email me after Mar 8th if this message is still here: mailto://klahnakoski@mozilla.org

==Introduction==

The objective of the Code Coverage project is to provide daily code coverage details and summary statistics. The assumption is that
code coverage statistics and details can help judge code quality. We expect this information to be useful to
* Release managers - Provide them with another metric to help measure risk a particular changeset, or family of changesets, adds to a release
* Module owners - Provide drill down coverage statistics so test coverage is focused on the most important part of the code
* Individual developers - To see if their new code require new tests to cover it, or if tests already cover their new code
* Our own test-infrastructure team - We can reduce the number of machines dedicated to testing, if we know where tests overlap, and focus on tests that cover recent changes.

Generally, we would like to know
* Is code coverage going up or down?
* If code coverage is going down, what new code is not being covered? Is it OK to not be covered?
* If code coverage is going down, what tests have been dropped? Is that OK?
* Should we alert when code coverage goes down "significantly"?
* When adding or change code in source file S, what tests cover that source file? What tests should we run?

==Getting Started==

* Getting Started with Code Coverage - https://public.etherpad-mozilla.org/p/coverage_quickstart

==User Interface==

* GUI objective - http://people.mozilla.org/~choller/firefox/coverage/mc-coverage-20130210-29dd80c95b7d/

==Code==
* '''UI''' - https://github.com/chinhodado/codecoverage_presenter
* '''ETL''' - https://github.com/klahnakoski/ActiveData-ETL/blob/dev/activedata_etl/transforms/jscov_to_es.py

==Contacts==

* jmaher@mozilla.com
* klahnakoski@mozilla.com
* gmierz1@live.ca
* chmanchester@mozilla.com

Many of us are live at #ateam @ irc.mozilla.org during usual North American work hours.

==Reference docs ==

The following is optional reading, for reference purposes only.

* Previous term CodeCoverage meeting notes (optional, reference only) - https://public.etherpad-mozilla.org/p/ucosp_meeting_notes

EngineeringProductivity/Projects/Stockwell/Meetings/2017-02-14

2017-02-14T16:59:40Z

Klahnakoski: fix link

= Previous Action Items =

= Status =

* [jmaher] - P1 intermittent trend:
** [https://docs.google.com/spreadsheets/d/1PFE_BTw1qmln4EvxVLQZSjCjlNa-uRQOC79XFbpMA0o/edit?usp=sharing last 6 weeks]
** last week: 61 bugs
** 4 weeks ago: 74 bugs

Project updates:
* {{bug|1328351}} - [jmaher] add BUG_COMPONENT to all files in-tree- maybe 55% done
* {{bug|1323044}} - [malayaleecoder] add a lint job for mochitest (about 60% done)
* {{bug|1322433}} - [wlach] - make it easier to retrigger a job with options (precursor to rr-chaos in a test-lint job)
* <s>{{bug|1324470}} - [gbrown] - add a mach command to display test results from activedata - up for review (landed)</s>
* <s>[ekyle] - updated [https://people-mozilla.org/~klahnakoski/NeglectedOranges/index.html neglected oranges]</s>
* TODO:
** dashboard of test by component
** better way to track disabled tests (test-informant might work)
** create common workflows for intermittents and data - specifically what triagers should do and what is expected of test owners.

= Discussion Topics =
* much higher orangefactor and high frequency bugs this week- how to spot this early on and find the root causes?
* Auto classification
* https://people-mozilla.org/~klahnakoski/testfailures

= New Ideas to investigate =
*

= Action Items =
* Discussion topics for next time
**
**
*

EngineeringProductivity/Projects/Stockwell/Meetings/2017-02-14

2017-02-14T16:57:04Z

Klahnakoski: add link

= Previous Action Items =

= Status =

* [jmaher] - P1 intermittent trend:
** [https://docs.google.com/spreadsheets/d/1PFE_BTw1qmln4EvxVLQZSjCjlNa-uRQOC79XFbpMA0o/edit?usp=sharing last 6 weeks]
** last week: 61 bugs
** 4 weeks ago: 74 bugs

Project updates:
* {{bug|1328351}} - [jmaher] add BUG_COMPONENT to all files in-tree- maybe 55% done
* {{bug|1323044}} - [malayaleecoder] add a lint job for mochitest (about 60% done)
* {{bug|1322433}} - [wlach] - make it easier to retrigger a job with options (precursor to rr-chaos in a test-lint job)
* <s>{{bug|1324470}} - [gbrown] - add a mach command to display test results from activedata - up for review (landed)</s>
* <s>[ekyle] - updated [https://people-mozilla.org/~klahnakoski/NeglectedOranges/index.html neglected oranges]</s>
* TODO:
** dashboard of test by component
** better way to track disabled tests (test-informant might work)
** create common workflows for intermittents and data - specifically what triagers should do and what is expected of test owners.

= Discussion Topics =
* much higher orangefactor and high frequency bugs this week- how to spot this early on and find the root causes?
* Auto classification
* https://people-mozilla.org/~klahnakoski/testfailures/#sampleMax=2017-02-14&sampleMin=2017-01-15

= New Ideas to investigate =
*

= Action Items =
* Discussion topics for next time
**
**
*

MOSS/Foundational Technology/Projects We Use

2017-02-09T15:18:13Z

Klahnakoski: add ES person, me!

This is an incomplete list of the free software and open source projects Mozilla relies upon. As a starting point, it lists each project along with a short statement of how we depend on it. Where practical it would also be helpful to identify a Mozillian most closely associated with our use of each project.

Note that presence on this list isn't the same as, nor is it a prerequisite for, applying for the MOSS "Foundational Technology" track - projects have to make an application using the process on the [[MOSS/Foundational Technology|Foundational Technology]] page.

This is a work in progress - please contribute to this list.

{| class="wikitable"
|-
! Project !! Description !! Contact within Mozilla
|-
| [https://angularjs.org/ angular.js] || Used by A-Team for web apps (eg Treeherder) || Member of Jonathan Griffin's team
|-
| [https://httpd.apache.org Apache Server] || Used by A-Team for web apps || Member of Jonathan Griffin's team
|-
| [https://github.com/ansible/ansible Ansible] || Used by IT (netops) and A-Team to manage deployments || jbarnell , Webops, GPS?
|-
| [https://github.com/h4writer/arewefastyet AreWeFastYet] || Compare JS performance across JS engines and platforms || Hannes Verschore
|-
| [https://atom.io/ Atom] || Used (either vanilla or e.g. as [https://github.com/Microsoft/vscode] ) by various developers ||
|-
| [https://babeljs.io/ BabelJS] || JavaScript compiler, Used by Gaia, TaskCluster team || Selena Deckelmann
|-
| [https://www.isc.org/downloads/bind/ BIND] || DNS Server || Brian Hourigan
|-
| [https://pypi.python.org/pypi/bleach/ Bleach] || HTML sanitizing library that escapes or strips markup and attributes used by MDN and a bunch of Mozilla sites || Will Kahn-Greene
|-
| [https://pypi.python.org/pypi/blessings/ Blessings] || Terminal formatting lib used by mozilla-central build process || Erik Rose
|-
| [http://getbootstrap.com/ Bootstrap] || HTML/CSS/JS framework, used by many of Mozilla's sites. || Webdev
|-
| [http://brew.sh/ brew / Homebrew] || Mac OS X packaging system, used to install dev tools || Sam Penrose
|-
| [https://bro.org bro] || The Bro Network Security Monitor || Michal Purzynski
|-
| [http://browserify.org Browserify] || Build JS dependencies for the browser || mozilla-services (kinto.js)
|-
| [http://buildbot.net/ BuildBot] || The base system currently in use for release || Dustin J. Mitchell
|-
| [http://bugzilla.org/ Bugzilla] (upstream) || The base Bugzilla on that we customize for Mozilla's use || Mark Côté
|-
| [http://www.celeryproject.org/ Celery] || Distributed task queue. Used by Treeherder and others. || Member of Jonathan Griffin's team
|-
| [http://ckeditor.com/ CKEditor] || WYSIWYG editor on MDN ||
|-
| [http://chaijs.com/ Chai] || JavaScript test and assertion library || Cloud Services, Tarek Ziade's team (kinto.js), Firefox Hello team
|-
| [http://www.llvm.org Clang/LLVM] || C/C++ compiler and infrastructure || Ehsan Akhgari & Sylvestre Ledru
|-
| [https://codemirror.net/ CodeMirror] || Used in DevTools, [https://thimble.mozilla.org Thimble], and other online code tools || David Humphrey/Simon Wex
|-
| [https://pypi.python.org/pypi/cookiecutter/ Cookiecutter] || Templating system used to clone our [https://github.com/mozilla/sugardough Sugardough] Django template || Giorgos Logiotatidis
|-
| [https://conemu.github.io/ ConEmu] || Console emulator for Windows. Used by devs running Windows. || Ed Morley
|-
| [http://curl.haxx.se/ curl] || internet transfer tool and library, used by crashreporter and FirefoxOS || Daniel Stenberg
|-
| [https://www.debian.org/ Debian] || Used on many developer boxes || Sylvestre Ledru or glandium
|-
| [http://deis.io Deis] || Open Source Heroku-like PaaS platform. Hosts www.mozilla.org, masterfirefoxos.mozilla.org, etc. || Member of Benjamin Sternthal's team
|-
| [https://disconnect.me/trackerprotection Disconnect.me ] || Open, transparent, neutral Tracking Protection blocklist used in Firefox Private Browsing Windows || Marshall Erwin, Javaun Moradi, Francois Marier
|-
| [https://discourse.org Discourse] || [https://discourse.mozilla-community.org Community], [https://discourse.webmaker.org/ Webmaker], [https://discourse.mozilla-advocacy.org/ Advocacy], et al || [[IT/Community/WG/Discourse|Community Ops]] (Yousef Alam or Tanner Filip)
|-
| [https://djangoproject.com Django] || Backend web framework used on many of our websites, including addons.mozilla.org, marketplace.mozilla.org, support.mozilla.org, Input, Snippets, MDN (Mozilla Developer Network), mozilla.org, Treeherder || Andy McKay and Jannis Leidel are (or have been) on the [https://www.djangoproject.com/foundation/ Django Software Foundation] board, Jannis is core team member
|-
| [http://www.django-rest-framework.org Django REST framework] || API framework. Used by various Mozilla sites including MDN, Firefox marketplace, mozilla.org, support.mozilla.com. || Andy McKay and Jannis Leidel
|-
| [https://github.com/docker/docker Docker] || Used by release engineering for Linux build and test containers and by ateam for managing test and production services. Used by many Mozilla websites as well such as addons.mozilla.org, marketplace.mozilla.org. (Plus docker-compose and docker machine) || Member of Selena Deckelmann's team
|-
| [https://eclipse.org/ Eclipse] || Integrated Development Environment used by many developers || —
|-
| [https://www.elastic.co/products/elasticsearch elasticsearch] || Search engine for various web sites and analytics || Erik Rose (dxr), Kyle Lahnakoski (ActiveData)
|-
| [http://www.gnu.org/software/emacs/ emacs] || Programmable editor used by many developers || —
|-
| [http://eslint.org/ eslint] || Pluggable linting utiltity used by Firefox Hello, DevTools and Firefox Android || Mark Banner
|-
| [https://github.com/ether/etherpad-lite Etherpad] || Used for meeting notes, etc || JP Schneider
|-
| [https://flake8.readthedocs.org/ flake8] || Wrapper around Python linters. Used by Treeherder and others. || Member of Jonathan Griffin's team
|-
| [http://flask.pocoo.org/ Flask] || Python web framework || Erik Rose
|-
| [https://fortawesome.github.io/Font-Awesome/ Font Awesome] || Font and CSS toolkit, used by many of Mozilla's sites. || Webdev
|-
| [http://foundation.zurb.com/ Foundation Framework] || Responsive front-end framework, used by some Mozilla sites and add-ons || Luke Crouch
|-
| [http://gcc.gnu.org GCC] || C/C++ compiler and infrastructure || Nathan Froyd
|-
| [https://git-scm.com/ Git] || Version control system - https://git.mozilla.org || Unknown
|-
| [http://gunicorn.org/ gunicorn] || Python WSGI HTTP Server. Used by Treeherder, Socorro, Pontoon. || Webdev
|-
| [http://www.freedesktop.org/wiki/Software/HarfBuzz/ HarfBuzz] || International text shaping engine used in Firefox/Servo || Platform team
|-
| [http://hunspell.sourceforge.net/ Hunspell] || Spellchecking engine || Ehsan Akhgari
|-
| [https://github.com/hunspell/hyphen/ Hyphen] || Hyphenation library || Jonathan Kew
|-
| [https://github.com/jkbrzt/httpie HTTPie] || HTTP command-line client || Cloud Services (among many others), Tarek Ziade's team
|-
| [https://theintern.github.io/intern/ Intern] || Intern is a complete test system for JavaScript designed to help you write and run consistent, high-quality test cases for your JavaScript libraries and applications. || jrgm/vladikoff
|-
| [http://canonware.com/jemalloc/ jemalloc] || Memory allocation library || We can ask glandium
|-
| [http://jenkins-ci.org/ Jenkins CI] || Continuous integration system used by WebQA and EE || Unknown
|-
| [https://jquery.com/ jQuery] || JavaScript library, used by many of Mozilla's sites. || Webdev
|-
| [https://github.com/tmpvar/jsdom jsdom] || DOM implementation in full JS || Test suites in Cloud Services, Tarek Ziade's team (kinto.js)
|-
| [https://github.com/open-source-parsers/jsoncpp jsoncpp] || A C++ library for interacting with JSON, used by the crashreporter client and Socorro. || Gabriele Svelto
|-
| [https://kafka.apache.org/ Kafka] || Distributed transaction log, used for hg.mozilla.org replication. || gps
|-
| [http://kombu.readthedocs.org/ Kombu] || Messaging library for Python. Used by Treeherder and others. || Member of Jonathan Griffin's team
|-
| libbz2 || Compression library for .bz2 format || Julian Seward
|-
| libjpeg-turbo || JPEG decoding library || Jeff Muizelaar
|-
| [http://www.libpng.org/pub/png/libpng.html libpng] || PNG decoding library || Jeff Muizelaar
|-
| libvpx (Google) || Library for support of Google’s VP* family of codecs || Tim Terriberry
|-
| Linux || OS kernel used in Firefox OS || Unknown
|-
| LLVM || Compiler foundation for ASAN, static analysis tools, Rust || Unknown
|-
| [https://lodash.com/ lodash] || JavaScript utility library, used by many of Mozilla's sites. || Webdev & Firefox Hello
|-
| [https://github.com/macvim-dev/macvim MacVim] || Mac wrapper around Vim || -
|-
| [https://www.list.org/ Mailman] || [https://mail.mozilla.org/listinfo Mailing lists] || Unknown
|-
| [https://www.mediawiki.org/wiki/MediaWiki MediaWiki] || You are reading this on a wiki || Sheeri Cabral
|-
| [https://www.mercurial-scm.org/ Mercurial] || Version control system and source code management || GPS
|-
| [http://mochajs.org/ Mocha] || JavaScript test runner || Cloud Services, Tarek Ziade's team (kinto.js); Firefox Hello team
|-
| [https://github.com/kumar303/mohawk Mohawk] || Python library for Hawk HTTP authorization. Used by Treeherder and others. || Member of Jonathan Griffin's team
|-
| [http://mozdef.com mozdef] || Security event monitoring and incident response || Jeff Bryner
|-
| [http://www.mingw.org/wiki/msys msys] || Used to build Firefox on Windows. Note: It's likely best we support the newer MSYS2 project instead: https://github.com/msys2 || Unknown
|-
| [https://www.mysql.com/ MySQL] || Open source relational DB used by many developers, including AMO, SUMO, Input, bugzilla, releng, adminstered by IT || Sheeri Cabral
|-
| [https://www.nagios.org/ Nagios] || IT management system. Used for notifications of system failures || Sheeri Cabral, Ashish V.
|-
| [http://netsniff-ng.org/ netsniff-ng] || Linux networking toolkit || Michal Purzynski
|-
| nICEr || Library for traversing firewalls || Unknown
|-
| [https://nixos.org NixOS] || Reproducible Linux distribution. Used by some developers || Nicolas B. Pierron
|-
| [https://nodejs.org Node.js] || JavaScript runtime for server side applications, command line utilities || Nick Desaulniers
|-
| nrappkit || Toolkit for building standalone applications || Unknown
|-
| OpenH264 (Cisco) || H.264 video library || Unknown
|-
| [http://openresty.org OpenResty] || a fast web app server by extending nginx, used by cloudops || Benson Wong (mostlygeek)
|-
| [http://www.openssh.com/ OpenSSH] || Remote server management, secure transport for Git and Mercurial || Unknown
|-
| [https://www.openstreetmap.org OpenStreetMap] || Online/offline maps, used by the location service and on mozilla.org || Unknown
|-
| [http://www.openLDAP.org/ OpenLDAP] || User management used by Infra || :jabba?
|-
| [https://openvpn.net/ Openvpn] || VPN used by Infra || :jabba?
|-
| [http://www.inspircd.org/ inspircd] || Irc server used by mozilla || :ashish
|-
| [http://openssl.org/ OpenSSL] || Cryptograpahy and TLS Toolkit || Nick Desaulniers
|-
| [https://github.com/khaledhosny/ots OTS] || OpenType sanitizer used by Firefox to protect against security bugs in underlying platforms related to malicious fonts || Jonathan Kew
|-
| [https://www.owasp.org/index.php/ZAP OWASP ZAP] || Web security testing tool used by security and QA teams || Simon Bennetts (psiinon)
|-
| [https://owncloud.org/ Owncloud] || Open platform to host your cloud under your control || Some communities have been using it to host files under their control (ask Nukeador)
|-
| [https://pypi.python.org/pypi/parsimonious/ Parsimonious] || Parsing lib used by DXR and a few other sites (I think) || Erik Rose
|-
| [https://github.com/mozilla/pdf.js PDF.js] || Used as the PDF Viewer in Firefox and Firefox OS || Brendan Dahl, Yury Delendik
|-
| [https://github.com/PyCQA/pep8 pep8] || Python linter. Used by Treeherder and others. || Member of Jonathan Griffin's team
|-
| [https://www.perl.org/ Perl] || Used by Bugzilla || Member of Jonathan Griffin's team
|-
| [http://python-pillow.org/ pillow] || Python Imaging library || Member of Webcompat team
|-
| [https://github.com/pypa/pip pip] || Python package tool. Used by all Python projects. || Erik Rose and Jannis Leidel, Jannis is core team member ([https://www.pypa.io/ PyPA])
|-
| [http://piwik.org/ Piwik] || Analytic software that gives you the control and respects privacy || Some communities have been using it to avoid GA analytics (Ask Nukeador)
|-
| [http://cmusphinx.sourceforge.net/ Pocketsphinx] || Speech recognition toolkit embedded into Firefox OS|| André Natal
|-
| [http://www.postgresql.org/ PostgreSQL] || Open source relational DB used by many developers, adminstered by IT || Selena Deckelmann
|-
| [https://github.com/PrismJS/prism Prism.js] || Syntax highlighting on code samples on MDN ||
|-
| [https://github.com/puppetlabs/puppet Puppet] || System administration tool || Member of Amy Rich's team, Corey Shield's team
|-
| [https://github.com/pyflakes/pyflakes pyflakes] || Python linter. Used by Treeherder and others. || Member of Jonathan Griffin's team
|-
| [http://pypy.org/ PyPy] || Python language runtime. Used by Web Push service. || Cloud Services, esp. Ben Bangert
|-
| [https://github.com/Pylons/pyramid/ Pyramid] || Python Web framework || Cloud Services team
|-
| [http://pytest.org/ pytest] || Python testing tool. Used by Treeherder and others. || Member of Jonathan Griffin's team
|-
| Python || Scripting language || [http://python.org/psf/ Python Software Foundation], Selena Deckelmann is a former board member
|-
| [https://pypi.python.org/pypi/pyelasticsearch/ pyelasticsearch] || Python client for elasticsearch || Erik Rose
|-
| [https://www.rabbitmq.com/ RabbitMQ] || Distributed Queue, used by Socorro, Pulse (all our publicly available build/test/commit information flows through this), Treeherder, addons.mozilla.org (with Celery), marketplace.mozilla.org (with Celery) || Selena Deckelmann
|-
| [http://facebook.github.io/react/index.html ReactJS] || Javascript library for building user interfaces. Used by Firefox Hello & DevTools || Mark Banner
|-
| [https://readthedocs.org/ Read the Docs] || Hosted automatically-built documentation, used by Cloud Services and a wide variety of mozilla Github projects || Ben Bangert, Jannis Leidel, Gervase Markham
|-
| [http://redis.io/ Redis] || Really fast data structure store, cache and message broker || Cloud Services Tarek Ziade's team, Loop Server (Hello) team
|-
| [http://python-requests.org/ Requests] || "Python HTTP Requests for Humans". Used by many many Mozilla Python projects. || Member of Jonathan Griffin's team
|-
| [https://www.reviewboard.org/ Review Board] || The base of MozReview, the new review tool being developed to replace Splinter || Steven MacLeod, Mike Conley
|-
| [http://wordlist.aspell.net/ SCOWL] || en-US word list used for spell checking. || ehsan
|-
| [http://www.seleniumhq.org/ Selenium] || Browser test driver || stephend/AutomatedTester or jrgm/vladikoff
|-
| [http://sinonjs.org/ Sinon] || JavaScript mock library || Cloud Services, Tarek Ziade's team (kinto.js); Firefox Hello team
|-
| [https://slimerjs.org/ SlimerJS] || Scriptable browser, based on Gecko, used for functional tests in some few Mozilla projects ( [[PluotSorbet]], some FxOS apps ? and others ?) || Myk Melez
|-
| [http://www.sqlalchemy.org/ SQLAlchemy]] || Database Toolkit and ORM for Python || bhearsum
|-
| [https://www.sqlite.org/ SQLite] || File-based database || khuey
|-
| [http://learnboost.github.io/stylus/ Stylus] || CSS Pre-processor on several sites || webdev
|-
| [https://subversion.apache.org/ Subversion] || https://svn.mozilla.org ''(Planning to decommission in near future)'' || Unknown
|-
| [http://http://suricata-ids.org/ suricata] || IDS / IPS / NSM engine || Michal Purzynski
|-
| [http://www.squid-cache.org/ Squid] || Caching proxy || Brian Hourigan
|-
| [https://tox.readthedocs.org/en/latest/ Tox] || Test automation || Tarek Ziade's Team
|-
| [https://travis-ci.org/ Travis] || Continuous integration system used by several teams (eg Treeherder) || Jonathan Griffin's team
|-
| [https://github.com/mitchellh/vagrant Vagrant]|| Build and distribute dev envs, used by Treeherder and others || Member of Jonathan Griffin's team
|-
| [http://valgrind.org/ Valgrind] || Memory error detection and profiling of C and C++ code || jseward, njn
|-
| [http://vim.org/ vim] || editor used by many developers || —
|-
| [https://waffle.io/mozilla/ waffle.io] || github project management used by various teams ||
|-
| [https://github.com/w3c/web-platform-tests web-platform-tests] || Testcases and tooling for cross-browser testing of web-platform APIs || jgraham
|-
| [http://www.webrtc.org WebRTC.org] || Components to support real-time communication in browsers and mobile applications || Randell Jesup
|-
| [http://www.wordpress.org WordPress] || Powers our blogs, blog.mozilla.org || Craig Cook
|-
| [https://xiph.org Xiph.Org] || Media codecs ship in Firefox, encoding tools || Ralph Giles
|-
| [http://zlib.net zlib] || Streaming compression and decompression for HTTP, PNG, etc. ||
|-
| [https://zookeeper.apache.org/ ZooKeeper] || Distributed synchronization, use by hg.mozilla.org replication || gps
|}

EngineeringProductivity/Meetings/2017-01-09

2017-01-09T16:44:25Z

Klahnakoski: /* Notices, Highlights, Roundtable */ add links

= Notices, Highlights, Roundtable =
* Significant Contributions
* Welcome Israel Madueme!
* Google Summer of Code, https://wiki.mozilla.org/Community:SummerOfCode17:Brainstorming
** Deadline to submit proposals is February 6
* Deadline to submit Global Wellness expenses is this Friday, January 13
* Deliverables and OKR's in 2017
** [https://docs.google.com/document/d/1OcQWksoBXmjXTTUXMqfqtlEQj4nQefXXV2kz7areUWs/edit Release & Productivity OKR's for 2017]
** [https://docs.google.com/spreadsheets/d/1xGa5tc0Ies5Hz6JTxv6FhD2bxy_JLUFF3uR7EXBDR7w/edit#gid=0 Engineering Productivity OKR's for Q1]
* Looking for 2-3 more JS interviewers to help choose an A-Team summer intern:
** [https://careers.mozilla.org/position/gh/500057 Internship offer] (look for "Engineering Productivity Intern")
** Jan will mentor, Maja and Will already volunteered for interviews (thanks!)
* [end of meeting] ActiveData - Kyle presents ActiveData, what is it?, what should the future be?
** [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Data%20Strategy%20170109.md Detailed document]
** [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Data%20Strategy%20170109.pdf Presentation (PDF)]

= Newsgroup and Blog Posts =

* [https://groups.google.com/forum/#!topic/mozilla.tools.bmo/YLGLdzdNucI Changing the default bug view for BMO] (dkl) (also [https://groups.google.com/forum/#!topic/mozilla.dev.platform/_AFaUi3JQhs cross-posted to dev.platform])
* [https://emceeaich.dreamwidth.org/198575.html How To Tag Comments in Bugzilla So We Can Respond Appropriately] (emceeaich)
* [https://groups.google.com/forum/#!topic/mozilla.governance/q9B3gPKq4uI Changes to etiquette.html in bugzilla.mozilla.org] (emceeaich)
* [https://emceeaich.dreamwidth.org/199563.html BMO Roadmap for the 1st Half of 2017] (emceeaich)
* [https://mrcote.info/ BMO in 2016] (mcote)
* [https://groups.google.com/forum/#!topic/mozilla.tools.bmo/tp4dSwUfKSA Moratorium on custom bug-entry form development] (mcote)
* [https://groups.google.com/forum/#!topic/mozilla.tools/KihdAlunkvo New process for Release & Productivity in 2017: RFCs] (wlach)

= Goal Updates =

= Other Project Updates =

= Holidays and Trips =

= Misc =

EngineeringProductivity/Meetings/2017-01-09

2017-01-09T13:10:41Z

Klahnakoski: /* Notices, Highlights, Roundtable */ activedata

= Notices, Highlights, Roundtable =
* Significant Contributions
* Welcome Israel Madueme!
* Google Summer of Code, https://wiki.mozilla.org/Community:SummerOfCode17:Brainstorming
** Deadline to submit proposals is February 6
* Deadline to submit Global Wellness expenses is this Friday, January 13
* Deliverables and OKR's in 2017
** [https://docs.google.com/document/d/1OcQWksoBXmjXTTUXMqfqtlEQj4nQefXXV2kz7areUWs/edit Release & Productivity OKR's for 2017]
** [https://docs.google.com/spreadsheets/d/1xGa5tc0Ies5Hz6JTxv6FhD2bxy_JLUFF3uR7EXBDR7w/edit#gid=0 Engineering Productivity OKR's for Q1]
* Looking for 2-3 more JS interviewers to help choose an A-Team summer intern:
** [https://careers.mozilla.org/position/gh/500057 Internship offer] (look for "Engineering Productivity Intern")
** Jan will mentor, Maja and Will already volunteered for interviews (thanks!)
* [end of meeting] ActiveData - Kyle presents ActiveData, what is it?, what should the future be?

= Newsgroup and Blog Posts =

* [https://groups.google.com/forum/#!topic/mozilla.tools.bmo/YLGLdzdNucI Changing the default bug view for BMO] (dkl) (also [https://groups.google.com/forum/#!topic/mozilla.dev.platform/_AFaUi3JQhs cross-posted to dev.platform])
* [https://emceeaich.dreamwidth.org/198575.html How To Tag Comments in Bugzilla So We Can Respond Appropriately] (emceeaich)
* [https://groups.google.com/forum/#!topic/mozilla.governance/q9B3gPKq4uI Changes to etiquette.html in bugzilla.mozilla.org] (emceeaich)
* [https://emceeaich.dreamwidth.org/199563.html BMO Roadmap for the 1st Half of 2017] (emceeaich)
* [https://mrcote.info/ BMO in 2016] (mcote)
* [https://groups.google.com/forum/#!topic/mozilla.tools.bmo/tp4dSwUfKSA Moratorium on custom bug-entry form development] (mcote)
* [https://groups.google.com/forum/#!topic/mozilla.tools/KihdAlunkvo New process for Release & Productivity in 2017: RFCs] (wlach)

= Goal Updates =

= Other Project Updates =

= Holidays and Trips =

= Misc =

Community:SummerOfCode17:Brainstorming

2017-01-07T20:06:01Z

Klahnakoski: /* Automation & Tools */ add proposal

Mozilla community members - submit proposals here for 2017 Google Summer of Code projects with Mozilla. (If this page looks empty, it's because accepted ideas have already been transferred to the [[Community:SummerOfCode17|official list]].) '''The''' absolute last '''deadline for submitting ideas''' in time to help us get accepted by Google '''is February 9th'''.

Are you a student looking to apply to SoC with Mozilla? Your first stop should be the [[Community:SummerOfCode17|official list of ideas]]. This page is full of weird and whacky ideas, some of which are still on here for a reason - it could be that they are not properly defined, the wrong size, or don't have a mentor. That makes them less likely to get accepted. You can, of course, also submit your own ideas - you don't have to put an idea on this page and get it 'made official' in order to send in a proposal for it.

==How To Write A Good Project Proposal==

Before adding an proposal to this list, please consider the following:

* '''Be specific'''. It's hard to understand the impact of, or the size of, vague proposals.
* '''Consider size'''. The student has eight weeks to design, code, test and document the proposal. It needs to fill, but not overfill, that time.
* '''Do your research'''. Support the idea with well-researched links.
* '''Don't morph other people's ideas'''. If you have a related idea, place it next to the existing one, or add a comment.
* '''Insert only your own name into the Mentor column''', and then only if you are willing to take on the responsibility. If you think the SoC admins won't know who you are, leave contact details.
* '''Check back regularly'''. The administrators may have questions about your idea that you will need to answer.
* '''Know when to give up'''. If you've added the same idea for the last three years and it hasn't made it to the official page, perhaps you can predict what will happen this time.

==Suggestion List==

[[SummerOfCode|Here are the ideas lists from previous years]].

Proposals can be in almost any part of the Mozilla project - don't be fooled by the "Code" in "Summer of Code". If there is no category below for your part of Mozilla, add one!

== Mozilla Platform (Gecko) ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
! TaskCluster Improvements
! (placeholder)
! Backend (Node) JS, Github
! :dustin
! :dustin
! (will be something from [[TaskCluster/Round Tuit Box]])
|}

== Firefox ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| about:telemetry redesign
| about:telemetry is present on all builds of Firefox as a way for users to view the data being stored and sent via Telemetry. It was built before Firefox had multi-process Telemetry and without a clear design. This has resulted in a confusing HTML UI and barely-comprehensible JS.
| webtech (HTML+CSS+JS) and Design
| :chutten
| :chutten
|
|}

== Firefox Developer Tools ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== Firefox for Android ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== Thunderbird ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== Instantbird ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== Calendar ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== SeaMonkey ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== Bugzilla ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== Firefox Support (SUMO) ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== QA ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== Automation & Tools ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
! JS static analysis
! Bring some static analysis in our Firefox Javascript code
! Javascript experience, FLOW(?)
! Sylvestre
! same
!
|-
! C++ static analysis
! Add new checkers specific to our base code
! Strong C++ experience, clang
! Sylvestre
! Andi
!
|-
! JSON in Sqlite
! Query JSON Documents stored in Sqlite
! Database, SQL, Python
! Kyle Lahnakoski
! Kyle Lahnakoski
! [https://github.com/klahnakoski/JSONQueryExpressionTests/blob/master/docs/GSOC%20Proposal.md Details]
|-
|}

== Documentation ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== Mozilla Developer Network ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== Mozilla IT and Infrastructure ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== Sync / Services ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== Developer Tools ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== Add-on SDK ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== Foundation ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== OpenArt ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== Release Engineering ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== Emscripten ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== Rust ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
! Rust + WebAssembly showcase
! Rust and WebAssembly are going to be a great pair. Design and implement a simple and attractive web application, in Rust, that demonstrates the power of Rust on the web. Make fixes to upstream projects as necessary. Write a blog post about it.
! Rust, web development
! brson
! brson
! cc https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and-emscripten/7627
|-
! Rust dashboard updates
! Update rusty-dash.com to include additional metrics important to the project. This tool is vital to the day-to-day management of Rust, but it needs some dedicated attention to fulfill its promise.
! Rust
! brson
! brson
! Follow on work to https://internals.rust-lang.org/t/the-rust-project-needs-much-better-visibility-into-important-metrics/3367
|-
! Rust reproducible builds
! Make the Rust build process produce the identical binaries when run with identical configurations. This improves the security of the Rust ecosystem by allowing others to
double-check the official Rust builds
! Rust, compilers, systems programming
! brson
! brson
! https://internals.rust-lang.org/t/verifying-rustc-releases-with-reproducible-builds/4502
|-
! Abstract the Rust standard library
! The Rust standard library is very portable, but can be very, very portable. Refactor the
standard library to pull out a platform abstraction layer.
! Moderate Rust experience
! brson
! brson
! https://internals.rust-lang.org/t/refactoring-std-for-ultimate-portability/4301
|-
! Rust cross-platform showcase project
! Rust is very portable. Create a single showcase demo project that compiles for Windows, OS X, Linux, Android, iOS, wasm, and microcontrollers. Use real crates to accomplish some real task. Set up CI for all platforms on Travis. To be used as a teaching tool and for regression testing.
! Moderate Rust experience
! brson
! brson
!
|-
! rustc micro-optimization bonanza
! Just go hog wild finding microoptimizations in rustc. Write a blog post bragging about it.
! Performance optimization
! brson
! brson
!
|-
! Rust-specific benchmark suite
! Today Rust uses perf.rust-lang.org to track _compile time_ performance, but nothing to track _runtime_ performance. Work with the Rust developers to create a benchmark suite specific to Rust.
! Programming
! brson
! brson, nrc?
!
|-
|}

== Servo ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== Security Engineering ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|}

== Localization ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== Build system ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== Security Assurance ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== WADI ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== Mozilla Science Lab ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}

== MozVR ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Reporter
! Mentor(s)
! Comments
|-
|}

== Connected Devices ==

{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Reporter
! Mentor(s)
! Comments
|-
|}

Auto-tools/Projects/DevelopmentMetrics

2016-12-10T22:30:39Z

Klahnakoski: more alert fixes

== Overview ==

These charts serve two purposes. The first is to satisfy one of the specific needs of the [[Bugzilla Anthropology|Bugzilla Anthropology Project]] which was to provide a view into patch review times. The second is to prove
ElasticSearch can be used a performant [http://en.wikipedia.org/wiki/Data_warehouse data warehouse].
More on the project and conclusions can be found at the [https://wiki.mozilla.org/index.php?title=Bugzilla_Anthropology/2013-01-29 Jan 2013 project summary].
There is also my [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pdf DashCon presentation]( [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pptx PPT])

== Bug Counts ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-Counts.html Bug Counts] || Open bug count over time, with open/close rates, and median age. Filter bugs by time range, components, and common program markups. This dashboard is meant as a rough-first-step to building something more process specific.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-CloseRate.html#sampleInterval=week&sampleMax=2014-01-25&sampleMin=2012-05-27 Bug Close Rate] || Counts bug closures, and requires writing Elasticsearch filters to limit view to desired category of bugs.
|}

==Patch Reviews==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byTop.html Top 30 Reviewers] Requires VPN and disabled mixed content blocking
| Shows the top reviewers from the past 6 weeks, the number of reviews they did, and the number in their queue right now. The original objective of this dashboard is to confirm some engineers have too many reviews. This dashboard is fine for identifying egregious differences, but poor for individual comparison; it seems personal style, team style, and code under review all impact the size and number of reviews done.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity_First.html Time to First Incoming Review]
 Requires VPN and disabled mixed content blocking
| Counts review requests and review completion rates. Also breaks down aggregate review age. The first review has been shown to take the longest, probably due to people synchronization issues. Subsequent reviews were almost instantaneous, so we exclude them. This dashboard is not good for fine grained comparison of teams because the nature of the bugs, and the process used, is often too different. The response time INCLUDES WEEKENDS.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byReviewer.html Incoming Review by Individual] Requires VPN and disabled mixed content blocking
| Top reviewers, but this time with some breakdown by week and component. Interesting, but not actionable.
|- style="vertical-align:top;"
| [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity.html Incoming Reviews]
 Requires VPN and disabled mixed content blocking
| Statistics for all reviews. Subsequent reviews of a bug happen much faster than the first. Maybe the fast review speed is an administrative anomaly; reviews are added after the fact, and marked as reviewed. Maybe, the requester and reviewer are working closely to remove the remaining nits.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Reviews_Pending_18.html Reviews Requested in the Past 18 weeks]
| An attempt to better understand the aggregate response time; while treating "old" reviews (those over 18weeks), as something else entirely.
|}

==Engineering Dashboards==

Dashboards for use by developers, or our own team

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://people.mozilla.org/~klahnakoski/NeglectedOranges/index.html Neglected Oranges]
| List of current, intermittent test failures, and have een no bug activity in the past week.
|}

==Release Management Dashboards==

[https://wiki.mozilla.org/Release_Management Release Management] are responsible for quality, security, and stability.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform/releases.html Release Dashboard]
| All outstanding bugs tracked by the Release Management
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform-history/release-history.html Release Uplifts]
| Count the number of patches that have been uplifted to the Aurora and Beta branches.
|}

== Contributors ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/contributors/dashboard.html# Contributors Dashboard]
| [https://wiki.mozilla.org/EngineeringProductivity Engineering Productivity's] list of contributor bugs that may benefit from some action on our part.
|}

==Project Dashboards and Burndown==

These dashboards are for showing general project state and burndown.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard_byProject.html Project Dashboard] Requires VPN
| Lists assigned bugs, patches in review, and patches awaiting landing
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Predictive_Simple.html#programFilter=B2G+1.3 Burndown Prediction] Requires VPN
| Uses average new bug rate, and average close rate to estimate the time it takes
to close all bugs in the given category. Compares to close rates necessary to meet due date
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard-FinalBurndown.html Final Burndown Dashboard] Requires VPN
| Basic burndown chart. Showing current bugs over time compared to ideal (linear) burndown
|}

Auto-tools/Projects/DevelopmentMetrics

2016-12-10T22:20:28Z

Klahnakoski: remove vpn indicator

== Overview ==

These charts serve two purposes. The first is to satisfy one of the specific needs of the [[Bugzilla Anthropology|Bugzilla Anthropology Project]] which was to provide a view into patch review times. The second is to prove
ElasticSearch can be used a performant [http://en.wikipedia.org/wiki/Data_warehouse data warehouse].
More on the project and conclusions can be found at the [https://wiki.mozilla.org/index.php?title=Bugzilla_Anthropology/2013-01-29 Jan 2013 project summary].
There is also my [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pdf DashCon presentation]( [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pptx PPT])

== Bug Counts ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-Counts.html Bug Counts] || Open bug count over time, with open/close rates, and median age. Filter bugs by time range, components, and common program markups. This dashboard is meant as a rough-first-step to building something more process specific.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-CloseRate.html#sampleInterval=week&sampleMax=2014-01-25&sampleMin=2012-05-27 Bug Close Rate] || Counts bug closures, and requires writing Elasticsearch filters to limit view to desired category of bugs.
|}

==Patch Reviews==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byTop.html Top 30 Reviewers] Requires VPN
| Shows the top reviewers from the past 6 weeks, the number of reviews they did, and the number in their queue right now. The original objective of this dashboard is to confirm some engineers have too many reviews. This dashboard is fine for identifying egregious differences, but poor for individual comparison; it seems personal style, team style, and code under review all impact the size and number of reviews done.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity_First.html Time to First Incoming Review]
| Counts review requests and review completion rates. Also breaks down aggregate review age. The first review has been shown to take the longest, probably due to people synchronization issues. Subsequent reviews were almost instantaneous, so we exclude them. This dashboard is not good for fine grained comparison of teams because the nature of the bugs, and the process used, is often too different. The response time INCLUDES WEEKENDS.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byReviewer.html Incoming Review by Individual] Requires VPN
| Top reviewers, but this time with some breakdown by week and component. Interesting, but not actionable.
|- style="vertical-align:top;"
| [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity.html Incoming Reviews]
| Statistics for all reviews. Subsequent reviews of a bug happen much faster than the first. Maybe the fast review speed is an administrative anomaly; reviews are added after the fact, and marked as reviewed. Maybe, the requester and reviewer are working closely to remove the remaining nits.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Reviews_Pending_18.html Reviews Requested in the Past 18 weeks]
| An attempt to better understand the aggregate response time; while treating "old" reviews (those over 18weeks), as something else entirely.
|}

==Engineering Dashboards==

Dashboards for use by developers, or our own team

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://people.mozilla.org/~klahnakoski/NeglectedOranges/index.html Neglected Oranges]
| List of current, intermittent test failures, and have een no bug activity in the past week.
|}

==Release Management Dashboards==

[https://wiki.mozilla.org/Release_Management Release Management] are responsible for quality, security, and stability.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform/releases.html Release Dashboard]
| All outstanding bugs tracked by the Release Management
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform-history/release-history.html Release Uplifts]
| Count the number of patches that have been uplifted to the Aurora and Beta branches.
|}

== Contributors ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/contributors/dashboard.html# Contributors Dashboard]
| [https://wiki.mozilla.org/EngineeringProductivity Engineering Productivity's] list of contributor bugs that may benefit from some action on our part.
|}

==Project Dashboards and Burndown==

These dashboards are for showing general project state and burndown.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard_byProject.html Project Dashboard] Requires VPN
| Lists assigned bugs, patches in review, and patches awaiting landing
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Predictive_Simple.html#programFilter=B2G+1.3 Burndown Prediction] Requires VPN
| Uses average new bug rate, and average close rate to estimate the time it takes
to close all bugs in the given category. Compares to close rates necessary to meet due date
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard-FinalBurndown.html Final Burndown Dashboard] Requires VPN
| Basic burndown chart. Showing current bugs over time compared to ideal (linear) burndown
|}

EngineeringProductivity/Meetings/2016-10-31

2016-10-28T19:11:01Z

Klahnakoski: add question

= Notices, Highlights, Roundtable =
* Significant Contributions
** Francesco Pischedda [:fpsd] - Fixed |mach lint| to ensure the same versions of flake8 are used locally as are used in automation ({{bug|1285555}})
* [jgriffin] Remember to submit your name for about:credits in Firefox - https://docs.google.com/forms/d/e/1FAIpQLSfgez4NGkespvSVblBkMDjWnsZm9PQQH41vbAnkOFQRGl30JQ/viewform
** https://www.mozilla.org/credits/

= Newsgroup and Blog Posts =

= Goal Updates =

= Other Project Updates =

= Holidays and Trips =

= Misc =

* [ekyle] Do we have a distributed process monitor? One with remote workers that can trigger jobs, and monitor them? Monit?

EngineeringProductivity/Projects/Stockwell/Meetings/2016-10-25

2016-10-25T14:32:34Z

Klahnakoski: add ekyle updates

= Previous Action Items =

= Status =
* [gbrown] - doing triage with orange factor data, determining what additional data makes triage and bug fixing easier
* [jmaher] - fixing a few infra intermittent bugs
* [jmaher] - starting to experiment with [[https://treeherder.mozilla.org/#/jobs?repo=try&revision=aa40ec3c1268917871b1457d7ac3309a919e5b0b&selectedJob=29483834&filter-searchStr=quarantine quarantine]] (thanks to [[https://mozillians.org/en-US/u/malayaleecoder/ :malayaleecoder]])
* [ekyle] - Neglected Oranges (new) https://people.mozilla.org/~klahnakoski/NeglectedOranges/index.html
* [ekyle] - OFv2 (not verified, on hold) https://people.mozilla.org/~klahnakoski/testfailures/

= Discussion Topics =
* Classification Tasks (aka Quarantine) ideas:
** Purgatory (frequent intermittent tests) - what is the point of running these if the job will always be orange? could we detect if a regression was introduced? Would we disable tests if they stayed here too long (say 30 days)?
** Quarantine (new/edited tests) - All tests which are edited/added would run for 2 weeks to ensure it isn't intermittent. If intermittent, would we move to Purgatory, backout original patch?
*** example [[https://treeherder.mozilla.org/#/jobs?repo=try&revision=9666ec40dfced1237aa6d5c269c9cfdb2f901ac9 try push]]
** Sanity (quick, very safe - 100% green) vs longer more complex/slightly intermittent. How would we define these safe tests? would we backout if any test here was intermittent? criteria for moving to main test suites (<10 intermittents total)?
** Making these changes will help keep our test jobs very green, without a purpose and workflow, these will add more confusion.
** are there concerns if something meets criteria on one platform, but not another?
** would our criteria change if this was disabled on one or more buildtypes/configs?

* Communication Format proposals:
** weekly communication to dev.platform like Memshrink tracking orange factor, new bugs, bugs fixed, major and upcoming milestones, tools
** monthly open format meetings for 2017- discuss data from stockwell weekly updates, ideas, concerns
** should we announce top intermittent bug fixers?
** should we track by module (webrtc, dom, layout, infra, etc.)? announce big module changes in intermittents?

= New Ideas to investigate =
* [jmaher] running each test in a fresh process/profile (measure runtime, failures)
* [jmaher] test case review- what criteria is useful for determining a potential intermittent?
*

= Action Items =
* Discussion topics for next time
** [wlach] reproduce top oranges with 'rr' (possibly 2 weeks out)
** [gbrown] summarize findings of triaging- propose changes to tools
**

EngineeringProductivity/Projects/ActiveData

2016-10-23T10:42:16Z

Klahnakoski: add end to end times

= Overview =

ActiveData is a collection of about 8 billion records (Feb 2016) covering unit tests, Buildbot jobs, performance data, and mercurial. This collection is publicly available, and can be queried directly, similar to any database.

ActiveData is built on top of ElasticSearch, a fast, distributed, redundant document store. ActiveData provides the benefits of familiar and succinct SQL by translating SQL-like queries to ElasticSearch queries,

== Problem ==
In order to improve our testing infrastructure we require data on how that infrastructure is performing. That information can be extracted from the raw logs, but that requires downloading samples, parsing data, insertion into a database (or worse, writing queries in an imperative language, like Python). When we are done an analysis we have effectively built an ETL pipeline that does not scale, and is too specific to be reused elsewhere. The next project does this work all over again.

== Solution==
ActiveData will serve as a reusable ETL pipeline; annotating the test results with as much relevant data as possible. It also provides a query service to explore and aggregate the data, so there is minimal setup required to access this data.

= Charts =

ActiveData is fast enough to support dashboards.

== Build times ==
{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/End-to-End.html End to End Times]
|| Shows overall time from when a build is first requested to the time tests on that build are complete.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/Builds-Overview.html Build Times]
|| Time series view of build times by platform and build type. Click on a bar to get a scatter plot view.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/Builds-Detail.html Detailed Build Times]
|| Scatter plot of build times. Use the left navigation panel to choose a combination. Click on a data point to see the Buildbot step times and Mozharness step times.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/Buildbot-Simulator.html Buildbot Simulator] incomplete
|| An incomplete Buildbot scheduling simulator. It can be used to see past wait times, queue size, and inter-job delays.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/index.html Test Runtimes]
|| Choose test suite and machine pool to get an average run time for each of the buildbot steps, and Mozharness steps.
|}

==Unit Test Visualization==
With all unit test results in ActiveData, we can get accurate estimates of "failure rate"; and be able to focus on the most-failing tests.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/testfailures/ Top Intermittent Failures]
|| List of top 30 most-failing unit tests, and list of top 30 most-recent failing tests. Click on the link to get a scatterplot.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/testfailures/test.html Find Test Results]
|| Use the search bar to find a test. A list of matching tests, and platform combinations will show the unit test failures and durations.
|-
| style="vertical-align:top;width:300px;" | [https://people.mozilla.org/~klahnakoski/NeglectedOranges/index.html Neglected Oranges]
|| Cross reference OrangeFactor and Bugzilla to give a list of frequent intermittents that have no bug activity.
|}

= Design =
ActiveData attempts to provide the benefits of an available database to the public; except larger and faster.

== Goals ==
An active data instance distinguishes itself from a static resource, or database, or big data solution, by delivering a particular set of features:
* '''A service, open to third party clients''' - By providing the service, clients don't need to setup their own datastore
* '''Fast filtering''' - Sub-second filtering over the contents of the whole datastore, independent of size, saves the application developer from declaring and managing indexes that do the same: There is sufficient information in the queries to determine which indexes should be built to deliver a quick response.
* '''Fast aggregates''' - Sub-second calculation of statistics over the whole datastore saves the application developer from building and managing caches of those aggregates.
* '''API is a query language (SQL?, MDX?)''' - Building upon the formalisms, and familiarity, of existing query languages, we reduce the learning curve, and also provide Active Data implementations with more insight into the intent of the client application; and optimize for its use cases.
* '''Uniform, Cartesian space of values''' - Mozilla has a mandate of data driven decision making. Data analysis tools, like Spreadsheets, R, Scipy, Numpy, and Pandas are used to perform data analysis, and they all require uniform data in multi-dimensional arrays, commonly known as "pivot tables" or "data frames". ActiveData's objective is to provide query results in these formats
* '''Metadata on dimensions and measures''' - ActiveData also provides context to the data it holds. It serves the purpose to allow exploration and discovery by third parties; by describing unit-of-measure, how dimensions relate to others, and provide human descriptions of the columns stored. This metadata is also invaluable in automating the orientation and formatting of dashboard charts: Knowing the domain of an axis allows code to decide the best (default) chart form, and provides logically reasonable aggregate options.
* '''Has a security model''' - Simpler applications can avoid the complications of a security model if it is baked into the ActiveData solution. If ActiveData is to become mainstream it is important that it can manage sensitive data and PII.

== Limitations ==

The unittest data is limited to those test suites that generate structured logs. Currently (Feb, 2016) the following do NOT have structured logs, and are NOT in ActiveData:

* cppunittest
* and any of the js based gaia suites (e.g Gij)

Specifically, you can see if a structured log is being generated: In Treeherder, click a job. Under the "Job details" pane at the bottom, look for a line similar to:

<blockquote> ''artifact uploaded: <suite>_raw.log''
</blockquote>

If you see that, it is using structured logging.

ActiveData makes specific tradeoffs to achieve its goals. It has the following limitations:
* large memory requirements
* low add/update/remove speeds
* strict data model (snowflake schema, hierarchical relations only)
* non-relational
* ETL work required to de-normalize data
* ETL work required to provide dimension metadata

== Non Goals ==
ActiveData is not meant to replace an application database. Applications often track significantly more data related to good interface design, process sequences, complex relations, and object life cycles.
ActiveData's simple model makes it difficult to track object life cycles and impossible to model many-to-many relations.
Data is not live, and definitely does not track "pending jobs" like TreeHerder or TaskCluster do. Test results may take a day, or more, to be indexed.

= Dependencies / Who will use this =
== Dependencies ==

ActiveData's ETL pipeline ingests data from a variety of sources:

* Buildbot
* Mozharness
* Structured Logs
* Task Cluster (end of Q1 2016)
* PerfHerder
* hg.mozilla.org

== Users ==

ActiveData's primary goal is to support dashboards that give Mozilla useful perspectives into the large amount of data:

* Individual unit test results
* Buildbot test times
* Firefox compile times
* Recently new, removed, and disabled tests
* Buildbot wait times

= Let's Use It! =

The service listens at http://activedata.allizom.org/query and accepts queries in [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md JSON Query Expression format].

curl -XPOST -d "{\"from\":\"unittest\"}" http://activedata.allizom.org/query

== The Query Tool ==
The ActiveData service is intended for use by automated clients, not humans. The [http://activedata.allizom.org/tools/query.html Query Tool] is a minimal web page for humans to do some exploration, and to test phrasing queries.
* [http://activedata.allizom.org/tools/query.html ActiveData QueryTool]

== Documentation ==
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md tutorial]
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Unittest%20Schema.md Unit test results schema]

= Code =
Development is still in the early stages, setting up your own service
* Github: https://github.com/klahnakoski/ActiveData
== Tests ==
* [https://github.com/klahnakoski/ActiveData/blob/master/tests/test_unittests.py testing code which sends some unittest-specific queries]

== Bugs ==
Bug are tracked in [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=activedata Bugzilla]. The open issues are shown here:
<bugzilla>
{
"quicksearch":"activedata"
}
</bugzilla>

= Contact =

* Kyle Lahnakoski
** IRC: ekyle@irc.mozilla.org
** Email: klahnakoski@mozilla.org
** Bugzilla: :ekyle

= More Context=
Mostly rambling, optional reading.

== Inspiration==
This project is inspired by the data warehouse and data mart technology that is common inside large corporations. These warehouses are useful because they are "active" services: This means the data is not only available, but it can be explored interactively by large audience using a query language.

== General Problem ==
A significant portion of any application is the backend database/datastore, which include:
* Managing resources and machines to support the datastore
* Data migrations on schemas during application lifetime
* Manually defining database indexes for responsive data retrieval
* Coding caching logic to reduce application latency

The manual effort put toward these features becomes significant as the amount of data grows in size and complexity. More importantly, this effort is being spent over and over on a multitude of applications, each a trivial variation of the next.

==General Solution==

Abstractly, we desire to reduce this redundant workload by adding a layer of abstraction called ActiveData: Clients using ActiveData benefit from the features it provides and avoid the datastore management complexities. While the ActiveData implementers can focus on these common issues while being given a simpler data model, and simpler query language, upon which to calculate optimizations.

Columnar datastores, have solved many (but not all) problems with changing schema. Query-directed indexing has been around for decades in Oracle's query optimization algorithms, and are available for free in ElasticSearch. We now have the technology to build an ActiveData solution.

By defining an ActiveData standard, we can innovate on both sides of the ActiveData abstraction layer independently

== Client Architecture ==

Applications that leverage an active data warehouse can forgo significant server side development, if not all, and put the logic on the client side.

EngineeringProductivity/Projects/ActiveData

2016-10-23T10:28:38Z

Klahnakoski: add oranges

= Overview =

ActiveData is a collection of about 8 billion records (Feb 2016) covering unit tests, Buildbot jobs, performance data, and mercurial. This collection is publicly available, and can be queried directly, similar to any database.

ActiveData is built on top of ElasticSearch, a fast, distributed, redundant document store. ActiveData provides the benefits of familiar and succinct SQL by translating SQL-like queries to ElasticSearch queries,

== Problem ==
In order to improve our testing infrastructure we require data on how that infrastructure is performing. That information can be extracted from the raw logs, but that requires downloading samples, parsing data, insertion into a database (or worse, writing queries in an imperative language, like Python). When we are done an analysis we have effectively built an ETL pipeline that does not scale, and is too specific to be reused elsewhere. The next project does this work all over again.

== Solution==
ActiveData will serve as a reusable ETL pipeline; annotating the test results with as much relevant data as possible. It also provides a query service to explore and aggregate the data, so there is minimal setup required to access this data.

= Charts =

ActiveData is fast enough to support dashboards.

== Build times ==
{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/Builds-Overview.html Build Times]
|| Time series view of build times by platform and build type. Click on a bar to get a scatter plot view.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/Builds-Detail.html Detailed Build Times]
|| Scatter plot of build times. Use the left navigation panel to choose a combination. Click on a data point to see the Buildbot step times and Mozharness step times.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/Buildbot-Simulator.html Buildbot Simulator] incomplete
|| An incomplete Buildbot scheduling simulator. It can be used to see past wait times, queue size, and inter-job delays.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/index.html Test Runtimes]
|| Choose test suite and machine pool to get an average run time for each of the buildbot steps, and Mozharness steps.
|}

==Unit Test Visualization==
With all unit test results in ActiveData, we can get accurate estimates of "failure rate"; and be able to focus on the most-failing tests.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/testfailures/ Top Intermittent Failures]
|| List of top 30 most-failing unit tests, and list of top 30 most-recent failing tests. Click on the link to get a scatterplot.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/testfailures/test.html Find Test Results]
|| Use the search bar to find a test. A list of matching tests, and platform combinations will show the unit test failures and durations.
|-
| style="vertical-align:top;width:300px;" | [https://people.mozilla.org/~klahnakoski/NeglectedOranges/index.html Neglected Oranges]
|| Cross reference OrangeFactor and Bugzilla to give a list of frequent intermittents that have no bug activity.
|}

= Design =
ActiveData attempts to provide the benefits of an available database to the public; except larger and faster.

== Goals ==
An active data instance distinguishes itself from a static resource, or database, or big data solution, by delivering a particular set of features:
* '''A service, open to third party clients''' - By providing the service, clients don't need to setup their own datastore
* '''Fast filtering''' - Sub-second filtering over the contents of the whole datastore, independent of size, saves the application developer from declaring and managing indexes that do the same: There is sufficient information in the queries to determine which indexes should be built to deliver a quick response.
* '''Fast aggregates''' - Sub-second calculation of statistics over the whole datastore saves the application developer from building and managing caches of those aggregates.
* '''API is a query language (SQL?, MDX?)''' - Building upon the formalisms, and familiarity, of existing query languages, we reduce the learning curve, and also provide Active Data implementations with more insight into the intent of the client application; and optimize for its use cases.
* '''Uniform, Cartesian space of values''' - Mozilla has a mandate of data driven decision making. Data analysis tools, like Spreadsheets, R, Scipy, Numpy, and Pandas are used to perform data analysis, and they all require uniform data in multi-dimensional arrays, commonly known as "pivot tables" or "data frames". ActiveData's objective is to provide query results in these formats
* '''Metadata on dimensions and measures''' - ActiveData also provides context to the data it holds. It serves the purpose to allow exploration and discovery by third parties; by describing unit-of-measure, how dimensions relate to others, and provide human descriptions of the columns stored. This metadata is also invaluable in automating the orientation and formatting of dashboard charts: Knowing the domain of an axis allows code to decide the best (default) chart form, and provides logically reasonable aggregate options.
* '''Has a security model''' - Simpler applications can avoid the complications of a security model if it is baked into the ActiveData solution. If ActiveData is to become mainstream it is important that it can manage sensitive data and PII.

== Limitations ==

The unittest data is limited to those test suites that generate structured logs. Currently (Feb, 2016) the following do NOT have structured logs, and are NOT in ActiveData:

* cppunittest
* and any of the js based gaia suites (e.g Gij)

Specifically, you can see if a structured log is being generated: In Treeherder, click a job. Under the "Job details" pane at the bottom, look for a line similar to:

<blockquote> ''artifact uploaded: <suite>_raw.log''
</blockquote>

If you see that, it is using structured logging.

ActiveData makes specific tradeoffs to achieve its goals. It has the following limitations:
* large memory requirements
* low add/update/remove speeds
* strict data model (snowflake schema, hierarchical relations only)
* non-relational
* ETL work required to de-normalize data
* ETL work required to provide dimension metadata

== Non Goals ==
ActiveData is not meant to replace an application database. Applications often track significantly more data related to good interface design, process sequences, complex relations, and object life cycles.
ActiveData's simple model makes it difficult to track object life cycles and impossible to model many-to-many relations.
Data is not live, and definitely does not track "pending jobs" like TreeHerder or TaskCluster do. Test results may take a day, or more, to be indexed.

= Dependencies / Who will use this =
== Dependencies ==

ActiveData's ETL pipeline ingests data from a variety of sources:

* Buildbot
* Mozharness
* Structured Logs
* Task Cluster (end of Q1 2016)
* PerfHerder
* hg.mozilla.org

== Users ==

ActiveData's primary goal is to support dashboards that give Mozilla useful perspectives into the large amount of data:

* Individual unit test results
* Buildbot test times
* Firefox compile times
* Recently new, removed, and disabled tests
* Buildbot wait times

= Let's Use It! =

The service listens at http://activedata.allizom.org/query and accepts queries in [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md JSON Query Expression format].

curl -XPOST -d "{\"from\":\"unittest\"}" http://activedata.allizom.org/query

== The Query Tool ==
The ActiveData service is intended for use by automated clients, not humans. The [http://activedata.allizom.org/tools/query.html Query Tool] is a minimal web page for humans to do some exploration, and to test phrasing queries.
* [http://activedata.allizom.org/tools/query.html ActiveData QueryTool]

== Documentation ==
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md tutorial]
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Unittest%20Schema.md Unit test results schema]

= Code =
Development is still in the early stages, setting up your own service
* Github: https://github.com/klahnakoski/ActiveData
== Tests ==
* [https://github.com/klahnakoski/ActiveData/blob/master/tests/test_unittests.py testing code which sends some unittest-specific queries]

== Bugs ==
Bug are tracked in [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=activedata Bugzilla]. The open issues are shown here:
<bugzilla>
{
"quicksearch":"activedata"
}
</bugzilla>

= Contact =

* Kyle Lahnakoski
** IRC: ekyle@irc.mozilla.org
** Email: klahnakoski@mozilla.org
** Bugzilla: :ekyle

= More Context=
Mostly rambling, optional reading.

== Inspiration==
This project is inspired by the data warehouse and data mart technology that is common inside large corporations. These warehouses are useful because they are "active" services: This means the data is not only available, but it can be explored interactively by large audience using a query language.

== General Problem ==
A significant portion of any application is the backend database/datastore, which include:
* Managing resources and machines to support the datastore
* Data migrations on schemas during application lifetime
* Manually defining database indexes for responsive data retrieval
* Coding caching logic to reduce application latency

The manual effort put toward these features becomes significant as the amount of data grows in size and complexity. More importantly, this effort is being spent over and over on a multitude of applications, each a trivial variation of the next.

==General Solution==

Abstractly, we desire to reduce this redundant workload by adding a layer of abstraction called ActiveData: Clients using ActiveData benefit from the features it provides and avoid the datastore management complexities. While the ActiveData implementers can focus on these common issues while being given a simpler data model, and simpler query language, upon which to calculate optimizations.

Columnar datastores, have solved many (but not all) problems with changing schema. Query-directed indexing has been around for decades in Oracle's query optimization algorithms, and are available for free in ElasticSearch. We now have the technology to build an ActiveData solution.

By defining an ActiveData standard, we can innovate on both sides of the ActiveData abstraction layer independently

== Client Architecture ==

Applications that leverage an active data warehouse can forgo significant server side development, if not all, and put the logic on the client side.

Auto-tools/Projects/DevelopmentMetrics

2016-10-23T10:16:14Z

Klahnakoski: Add neglected oranges

== Overview ==

These charts serve two purposes. The first is to satisfy one of the specific needs of the [[Bugzilla Anthropology|Bugzilla Anthropology Project]] which was to provide a view into patch review times. The second is to prove
ElasticSearch can be used a performant [http://en.wikipedia.org/wiki/Data_warehouse data warehouse].
More on the project and conclusions can be found at the [https://wiki.mozilla.org/index.php?title=Bugzilla_Anthropology/2013-01-29 Jan 2013 project summary].
There is also my [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pdf DashCon presentation]( [http://people.mozilla.org/~klahnakoski/docs/Bugs%20in%20ES.pptx PPT])

== Bug Counts ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-Counts.html Bug Counts] || Open bug count over time, with open/close rates, and median age. Filter bugs by time range, components, and common program markups. This dashboard is meant as a rough-first-step to building something more process specific.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Bug-CloseRate.html#sampleInterval=week&sampleMax=2014-01-25&sampleMin=2012-05-27 Bug Close Rate] || Counts bug closures, and requires writing Elasticsearch filters to limit view to desired category of bugs.
|}

==Patch Reviews==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byTop.html Top 30 Reviewers] Requires VPN
| Shows the top reviewers from the past 6 weeks, the number of reviews they did, and the number in their queue right now. The original objective of this dashboard is to confirm some engineers have too many reviews. This dashboard is fine for identifying egregious differences, but poor for individual comparison; it seems personal style, team style, and code under review all impact the size and number of reviews done.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity_First.html Time to First Incoming Review] Requires VPN
| Counts review requests and review completion rates. Also breaks down aggregate review age. The first review has been shown to take the longest, probably due to people synchronization issues. Subsequent reviews were almost instantaneous, so we exclude them. This dashboard is not good for fine grained comparison of teams because the nature of the bugs, and the process used, is often too different. The response time INCLUDES WEEKENDS.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Review-byReviewer.html Incoming Review by Individual] Requires VPN
| Top reviewers, but this time with some breakdown by week and component. Interesting, but not actionable.
|- style="vertical-align:top;"
| [http://people.mozilla.org/~klahnakoski/review/ReviewIntensity.html Incoming Reviews] Requires VPN
| Statistics for all reviews. Subsequent reviews of a bug happen much faster than the first. Maybe the fast review speed is an administrative anomaly; reviews are added after the fact, and marked as reviewed. Maybe, the requester and reviewer are working closely to remove the remaining nits.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/review/Reviews_Pending_18.html Reviews Requested in the Past 18 weeks] Requires VPN
| An attempt to better understand the aggregate response time; while treating "old" reviews (those over 18weeks), as something else entirely.
|}

==Engineering Dashboards==

Dashboards for use by developers, or our own team

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [https://people.mozilla.org/~klahnakoski/NeglectedOranges/index.html Neglected Oranges]
| List of current, intermittent test failures, and have een no bug activity in the past week.
|}

==Release Management Dashboards==

[https://wiki.mozilla.org/Release_Management Release Management] are responsible for quality, security, and stability.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform/releases.html Release Dashboard]
| All outstanding bugs tracked by the Release Management
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/platform-history/release-history.html Release Uplifts]
| Count the number of patches that have been uplifted to the Aurora and Beta branches.
|}

== Contributors ==

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/contributors/dashboard.html# Contributors Dashboard]
| [https://wiki.mozilla.org/EngineeringProductivity Engineering Productivity's] list of contributor bugs that may benefit from some action on our part.
|}

==Project Dashboards and Burndown==

These dashboards are for showing general project state and burndown.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard_byProject.html Project Dashboard] Requires VPN
| Lists assigned bugs, patches in review, and patches awaiting landing
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Predictive_Simple.html#programFilter=B2G+1.3 Burndown Prediction] Requires VPN
| Uses average new bug rate, and average close rate to estimate the time it takes
to close all bugs in the given category. Compares to close rates necessary to meet due date
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/modevmetrics/Dashboard-FinalBurndown.html Final Burndown Dashboard] Requires VPN
| Basic burndown chart. Showing current bugs over time compared to ideal (linear) burndown
|}

EngineeringProductivity/Projects/Everything

2016-10-19T15:39:50Z

Klahnakoski: typo

== Project Table ==

There is a project table that is a short list of the most active, projects: https://wiki.mozilla.org/EngineeringProductivity/Projects

== Motivation ==

This page exists to provide a low-maintenance list of all our projects. I do not beleive anyone knows how they '''all''' interact, but at least this list ensures here are no hidden moving parts.

''Template can be found below''

== The List ==

=== ActiveData ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
* '''Code''' - https://github.com/klahnakoski/ActiveData
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Buildbot JSON logs
** hg.mozilla.org
** OrangeFactor
** Perfherder
** Pulse exchange/build/normalized
** Structured Logs from Tests
** Talos
** Text logs (for buildbot and mozharness steps only)
* '''Outputs/Services'''
** Query endpoint: http://activedata.allizom.org/query
** Query Tool: http://activedata.allizom.org/tools/query.html

=== AlertManager ===

* '''Docs''' -https://github.com/jmaher/alert_manager/
* '''Code''' - https://github.com/jmaher/alert_manager/
* '''Contact' - jmaher@mozilla.com
* '''Inputs'''
** mozilla.dev.tree-management alerts from graph server
* '''Outputs/Services'''
** webUI for organizing and taking action on these alerts.

=== Autoland ===
* '''Docs''' - http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/autoland.html
* '''Code''' - http://hg.mozilla.org/hgcustom/version-control-tools/file/tip/autoland
* '''Contact''' - [:mcote], [:glob]
* '''Inputs'''
** MozReview UI & MozReview repo
* '''Outputs'''
** Commits land on the repository of record (or try)
** Status reported to MozReview

=== Autophone ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/AutoPhone
* '''Code''' - https://github.com/mozilla/autophone/
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
** http://phonedash.mozilla.org/ (used by who?)

=== Bugzilla / BMO ===
* '''Docs''' - https://bmo.readthedocs.io
* '''Code''' - https://github.com/mozilla-bteam/bmo
* '''Contact''' - Mark Cote, David Lawrence, Dylan Hardison
* '''Inputs'''
** Web UI
** WebServices API (REST, XMLRPC, JSONRPC)
* '''Outputs/Services'''
** https://bugzilla.mozilla.org (bug reporters, developers, etc)
** Pulse, Bugzfeed (via the [[https://wiki.mozilla.org/BMO/ChangeNotificationSystem]])
** BMO Push service (custom notifications for specific applications)

=== BugzFeed ===
* '''Docs''' - [[BMO/ChangeNotificationSystem]]
* '''Code''' - https://github.com/mozilla/bugzfeed
* '''Contact''' - mcote@mozilla.com
* '''Inputs'''
** BMO via [[Auto-tools/Projects/Pulse|Pulse]]
* '''Outputs/Services'''
** WebSocket servers:
*** bugzfeed.mozilla.org
*** bugzfeed-dev.allizom.org

=== Bugzilla/ES Cluster ===

* '''Docs''' - https://wiki.mozilla.org/BMO/ElasticSearch
* '''Code''' - https://github.com/klahnakoski/Bugzilla-ETL
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** Bugzilla (direct database access)
* '''Outputs/Services'''
** https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version

=== Buildbot ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
** hg.mozilla.org
* '''Outputs/Services'''
** builder slaves
** tester slaves
** https://wiki.mozilla.org/ReleaseEngineering/BuildAPI ??
** JSON Logs: http://builddata.pub.build.mozilla.org/builddata/buildjson/

=== C++ Code Coverage ===

* '''Docs''' - https://bugzilla.mozilla.org/show_bug.cgi?id=890116
* '''Contact''' - [:ahal]
* Used to be possible to trigger code coverage builds with 'try: -b o -p linux64-cc -u all -t none', but I think this is broken now. Probably isn't terribly hard to revive this. Needs further investigation.

=== charts.mozilla.org ===

* '''Docs''' -
* '''Code''' - https://github.com/mozilla/charts
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** BMO/ES Cluster (https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version)
* '''Outputs/Services'''
** http://charts.mozilla.org (for management)

=== CodeCoverage ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/CodeCoverage
* '''Code'''
** '''UI''' - https://github.com/chinhodado/codecoverage_presenter
** '''ETL''' - https://github.com/klahnakoski/ActiveData-ETL/blob/dev/activedata_etl/transforms/jscov_to_es.py
* '''Contact''' - jmaher@mozilla.com, klahnakoski@mozilla.com, chmanchester@mozilla.com
* '''Inputs'''
** Various tests have been configured with a code coverage option
* '''Outputs/Services'''
** ActiveData - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
** http://chinhodado.github.io/codecoverage_presenter/

=== Datazilla (retired) ===

* '''Docs''' - https://datazilla.readthedocs.org/en/latest/
* '''Code''' - https://datazilla.readthedocs.org/en/latest/
* '''Contact''' - See Treeherder
* '''Inputs'''
** data pushed from Talos (see Graph Server)
* '''Outputs/Services'''
** charts at https://datazilla.mozilla.org
** raw results at https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob

=== DevelopmentMetrics ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/DevelopmentMetrics
* '''Code''' - https://github.com/klahnakoski/MoDevMetrics
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Bugzilla/ES Cluster
* '''Outputs/Services'''
** various charts and dashboards

=== DevTools Harness ===

* '''Docs''' - Needs project page!
* '''Contact''' - [:ted.mielczarek]

=== dzAlerts (retired)===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Alerts
* '''Code''' - https://github.com/klahnakoski/datazilla-alerts
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Datazilla web service (https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob)
** Eideticket web service (http://eideticker.mozilla.org)
* '''Outputs/Services'''
** fxos-perf-alerts@mozilla.org (b2g sheriffs?)

=== Eideticker (retired) ===

* '''Docs''' - https://wiki.mozilla.org/Project_Eideticker#Documentation
* '''Code''' - https://github.com/mozilla/eideticker
* '''Contact''' - William Lachance, Dave Hunt
* '''Inputs'''
** Nightly/inbound b2g and android builds.
* '''Outputs/Services'''
** Eideticker dashboard (http://eideticker.mozilla.org)

=== Janitor ===
* '''Docs''' - https://mana.mozilla.org/wiki/display/ateam/Janitor
* '''Code''' - https://github.com/jankeromnes/janitor, https://github.com/jankeromnes/dockerfiles
* '''Contact''' - Jan Keromnes [:janx]
* '''Inputs'''
** (none yet)
* '''Outputs/Services'''
** https://janitor.technology
** BMO: new patches uploaded by users
** Treeherder: new pushes from users
** Docker Hub: image updates https://hub.docker.com/u/janx/

=== m21s ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/m21s
* '''Code''' - see project page
* '''Contacts''' - [:chmanchester][:ahal][:whimboo]
* '''Inputs'''
** Mozmill release tests
* '''Outputs'''
** 'Firefox Greenlight Tests' in Marionette, reporting to Treeherder

=== Marionette ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Marionette
* '''Code''' -
* '''Contact''' - [:AutomatedTester][:ato]
* '''What''' - Mozilla's native WebDriver implementation

=== Mozharness ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Mozharness
* '''Code''' - https://hg.mozilla.org/build/mozharness/
* '''Contact''' - [:armenzg]
* '''Inputs'''
** command-line invocation via buildbot or locally
* '''Outputs/Services'''
** build/test logs consumed by buildbot, Treeherder, TBPL

=== MozReview (Review Board) ===
* '''Docs''' - http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview.html
* '''Code''' - various pieces of https://hg.mozilla.org/hgcustom/version-control-tools; see docs for more.
* '''Contact''' - mcote, glob, smacleod
* '''Inputs'''
** BMO
** reviewboard-hg.mozilla.org
* '''Outputs/Services'''
** BMO
** Various repositories via Autoland

=== OrangeFactor ===

* '''Docs''' - [[Auto-tools/Projects/OrangeFactor]]
* '''Code''' - https://hg.mozilla.org/automation/orangefactor/
* '''Contact''' - :jgriffin, :mcote
* '''Inputs'''
** buildbot messages (using pulse)
** build logs
** comments from TBPL
** bugzilla bug data
* '''Outputs/Services'''
** https://brasstacks.mozilla.com/orangefactor/
** email status [War on Orange]

=== Ouija ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Ouija
* '''Code''' - https://github.com/dminor/ouija.git
* '''Contact''' - dminor, jmaher
* '''Inputs'''
** https://hg.mozilla.org/
** tbpl.mozilla.org
* '''Outputs/Services'''
** http://54.215.155.53

=== Perfherder ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/Perfherder
* '''Code''' - https://github.com/mozilla/treeherder/tree/master/treeherder/perf
* '''Contact''' - :wlach
* '''Inputs'''
** PERFHERDER_DATA
*** schema https://github.com/mozilla/treeherder/blob/master/schemas/performance-artifact.json
*** example http://wrla.ch/blog/2015/11/perfherder-onward/
* '''Outputs/Services'''
** https://treeherder.mozilla.org/perf.html#/graphs

=== Pulse ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Pulse
* '''Code''' - development library: https://hg.mozilla.org/automation/mozillapulse
* '''Contact''' - mcote
* '''Inputs'''
** a multitude of other systems
* '''Outputs/Services'''
** a multitude of other systems
** https://pulse.mozilla.org/

=== PulseGuardian ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Pulse/PulseGuardian
* '''Code''' - https://github.com/mozilla/pulseguardian/
* '''Contact''' - mcote
* '''Inputs'''
** Persona (for auth) (soon to be Okta or TaskCluster auth)
** Pulse
** Web UI
* '''Outputs/Services'''
** Pulse
** Email notifications

=== PulseTranslator ===
* '''Docs''' - https://github.com/mozilla/pulsetranslator/blob/master/README.md
* '''Code''' - https://github.com/mozilla/pulsetranslator
* '''Contact''' - jgriffin@mozilla.com
* '''Inputs'''
** Pulse exchange/build
* '''Outputs/Services'''
** Pulse exchange/build/normalized

=== Structured Logging ===
* '''Docs''' - https://mozbase.readthedocs.org/en/latest/loggingreporting.html, https://wiki.mozilla.org/Auto-tools/Projects/Structured_Logging
* '''Contacts''' - [:chmanchester][:ahal][:jgraham]

=== Talos ===
* '''Docs''' - https://wiki.mozilla.org/Buildbot/Talos
* '''Code''' - https://hg.mozilla.org/build/talos
* '''Contact''' - jmaher@mozilla.com
* '''Inputs'''
** build for desktop or android
** commandline (done via mozharness now) to specify which test(s) to run
* '''Outputs/Services'''
** log file with raw data
** uploaded summarization of data to graph server
** uploaded raw data to datazilla

Can be referred to as what is run by buildbot or by tbpl since this is the only performance test run on our per revision CI system. Other tools are run at a different cadence.

=== TBPL (retired) ===

* '''Docs''' - [[Sheriffing/TBPL]]
* '''Code''' - https://hg.mozilla.org/webtools/tbpl/
* '''Contact''' - [[Sheriffing/TBPL#Developer_Contacts]]
* '''Inputs'''
**
* '''Outputs/Services'''
**

=== Test Informant ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Test-Informant
* '''Code''' - See project page
* '''Contact''' - [:ahal]
* '''Inputs'''
** build notifications via pulse
** test manifests in tests.zip
* '''Outputs'''
** reports at e.g., http://brasstacks.mozilla.com/testreports/weekly

=== Treeherder ===
* '''Docs''' - [[Auto-tools/Projects/Treeherder]]
* '''Code''' - [[Auto-tools/Projects/Treeherder#Source_and_Docs]]
* '''Contact''' - [:camd][:mdoglio][:edmorley]
* '''Inputs'''
** Pushlog from hg.mozilla.org via json-pushes
** Build/tests from Buildbot via buildapi
** Direct pushes via ``treeherder-client``
** Build/tests from Taskcluster (under development)
* '''Outputs/Services'''
** https://treeherder.mozilla.org/
** https://treeherder.mozilla.org/api/

=== web-platform-tests ===
* '''Docs''' - https://wptrunner.readthedocs.org/en/latest/, Needs project page?
* '''Code'''
** https://github.com/w3c/web-platform-tests/
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/README.md
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/tests/README.md
* '''Contact''' - [:jgraham]

== Example ==

Use the EMPTY TEMPLATE to add more entries. Include ones you know about, even if you can not fill them.

=== EXAMPLE ===
* '''Docs''' - some wiki, or read the docs to learn more
* '''Code''' - link to code, if it makes sense
* '''Contact''' - for ekyle to contact if he has questions
* '''Inputs''' -
** automated resources
** services consumed
* '''Outputs/Services'''
** automated services provided
** dashboards (and teams that consume them)

=== EMPTY TEMPLATE ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
**

EngineeringProductivity/Projects/Everything

2016-10-04T20:20:47Z

Klahnakoski: Update the motivation to reflect the reality

== Project Table ==

There is a project table that is a short list of the most active, projects: https://wiki.mozilla.org/EngineeringProductivity/Projects

== Motivation ==

This page exists to provide a low-maintenance list of all out projects. I do not beleive anyone knows how they all interact, but at least this list ensures here are no hidden moving parts.

''Template can be found below''

== The List ==

=== ActiveData ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
* '''Code''' - https://github.com/klahnakoski/ActiveData
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Buildbot JSON logs
** hg.mozilla.org
** OrangeFactor
** Perfherder
** Pulse exchange/build/normalized
** Structured Logs from Tests
** Talos
** Text logs (for buildbot and mozharness steps only)
* '''Outputs/Services'''
** Query endpoint: http://activedata.allizom.org/query
** Query Tool: http://activedata.allizom.org/tools/query.html

=== AlertManager ===

* '''Docs''' -https://github.com/jmaher/alert_manager/
* '''Code''' - https://github.com/jmaher/alert_manager/
* '''Contact' - jmaher@mozilla.com
* '''Inputs'''
** mozilla.dev.tree-management alerts from graph server
* '''Outputs/Services'''
** webUI for organizing and taking action on these alerts.

=== Autoland ===
* '''Docs''' - http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/autoland.html
* '''Code''' - http://hg.mozilla.org/hgcustom/version-control-tools/file/tip/autoland
* '''Contact''' - [:mcote], [:glob]
* '''Inputs'''
** MozReview UI & MozReview repo
* '''Outputs'''
** Commits land on the repository of record (or try)
** Status reported to MozReview

=== Autophone ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/AutoPhone
* '''Code''' - https://github.com/mozilla/autophone/
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
** http://phonedash.mozilla.org/ (used by who?)

=== Bugzilla / BMO ===
* '''Docs''' - https://bmo.readthedocs.io
* '''Code''' - https://github.com/mozilla-bteam/bmo
* '''Contact''' - Mark Cote, David Lawrence, Dylan Hardison
* '''Inputs'''
** Web UI
** WebServices API (REST, XMLRPC, JSONRPC)
* '''Outputs/Services'''
** https://bugzilla.mozilla.org (bug reporters, developers, etc)
** Pulse, Bugzfeed (via the [[https://wiki.mozilla.org/BMO/ChangeNotificationSystem]])
** BMO Push service (custom notifications for specific applications)

=== BugzFeed ===
* '''Docs''' - [[BMO/ChangeNotificationSystem]]
* '''Code''' - https://github.com/mozilla/bugzfeed
* '''Contact''' - mcote@mozilla.com
* '''Inputs'''
** BMO via [[Auto-tools/Projects/Pulse|Pulse]]
* '''Outputs/Services'''
** WebSocket servers:
*** bugzfeed.mozilla.org
*** bugzfeed-dev.allizom.org

=== Bugzilla/ES Cluster ===

* '''Docs''' - https://wiki.mozilla.org/BMO/ElasticSearch
* '''Code''' - https://github.com/klahnakoski/Bugzilla-ETL
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** Bugzilla (direct database access)
* '''Outputs/Services'''
** https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version

=== Buildbot ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
** hg.mozilla.org
* '''Outputs/Services'''
** builder slaves
** tester slaves
** https://wiki.mozilla.org/ReleaseEngineering/BuildAPI ??
** JSON Logs: http://builddata.pub.build.mozilla.org/builddata/buildjson/

=== C++ Code Coverage ===

* '''Docs''' - https://bugzilla.mozilla.org/show_bug.cgi?id=890116
* '''Contact''' - [:ahal]
* Used to be possible to trigger code coverage builds with 'try: -b o -p linux64-cc -u all -t none', but I think this is broken now. Probably isn't terribly hard to revive this. Needs further investigation.

=== charts.mozilla.org ===

* '''Docs''' -
* '''Code''' - https://github.com/mozilla/charts
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** BMO/ES Cluster (https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version)
* '''Outputs/Services'''
** http://charts.mozilla.org (for management)

=== CodeCoverage ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/CodeCoverage
* '''Code'''
** '''UI''' - https://github.com/chinhodado/codecoverage_presenter
** '''ETL''' - https://github.com/klahnakoski/ActiveData-ETL/blob/dev/activedata_etl/transforms/jscov_to_es.py
* '''Contact''' - jmaher@mozilla.com, klahnakoski@mozilla.com, chmanchester@mozilla.com
* '''Inputs'''
** Various tests have been configured with a code coverage option
* '''Outputs/Services'''
** ActiveData - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
** http://chinhodado.github.io/codecoverage_presenter/

=== Datazilla (retired) ===

* '''Docs''' - https://datazilla.readthedocs.org/en/latest/
* '''Code''' - https://datazilla.readthedocs.org/en/latest/
* '''Contact''' - See Treeherder
* '''Inputs'''
** data pushed from Talos (see Graph Server)
* '''Outputs/Services'''
** charts at https://datazilla.mozilla.org
** raw results at https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob

=== DevelopmentMetrics ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/DevelopmentMetrics
* '''Code''' - https://github.com/klahnakoski/MoDevMetrics
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Bugzilla/ES Cluster
* '''Outputs/Services'''
** various charts and dashboards

=== DevTools Harness ===

* '''Docs''' - Needs project page!
* '''Contact''' - [:ted.mielczarek]

=== dzAlerts (retired)===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Alerts
* '''Code''' - https://github.com/klahnakoski/datazilla-alerts
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Datazilla web service (https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob)
** Eideticket web service (http://eideticker.mozilla.org)
* '''Outputs/Services'''
** fxos-perf-alerts@mozilla.org (b2g sheriffs?)

=== Eideticker (retired) ===

* '''Docs''' - https://wiki.mozilla.org/Project_Eideticker#Documentation
* '''Code''' - https://github.com/mozilla/eideticker
* '''Contact''' - William Lachance, Dave Hunt
* '''Inputs'''
** Nightly/inbound b2g and android builds.
* '''Outputs/Services'''
** Eideticker dashboard (http://eideticker.mozilla.org)

=== Janitor ===
* '''Docs''' - https://mana.mozilla.org/wiki/display/ateam/Janitor
* '''Code''' - https://github.com/jankeromnes/janitor, https://github.com/jankeromnes/dockerfiles
* '''Contact''' - Jan Keromnes [:janx]
* '''Inputs'''
** (none yet)
* '''Outputs/Services'''
** https://janitor.technology
** BMO: new patches uploaded by users
** Treeherder: new pushes from users
** Docker Hub: image updates https://hub.docker.com/u/janx/

=== m21s ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/m21s
* '''Code''' - see project page
* '''Contacts''' - [:chmanchester][:ahal][:whimboo]
* '''Inputs'''
** Mozmill release tests
* '''Outputs'''
** 'Firefox Greenlight Tests' in Marionette, reporting to Treeherder

=== Marionette ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Marionette
* '''Code''' -
* '''Contact''' - [:AutomatedTester][:ato]
* '''What''' - Mozilla's native WebDriver implementation

=== Mozharness ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Mozharness
* '''Code''' - https://hg.mozilla.org/build/mozharness/
* '''Contact''' - [:armenzg]
* '''Inputs'''
** command-line invocation via buildbot or locally
* '''Outputs/Services'''
** build/test logs consumed by buildbot, Treeherder, TBPL

=== MozReview (Review Board) ===
* '''Docs''' - http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview.html
* '''Code''' - various pieces of https://hg.mozilla.org/hgcustom/version-control-tools; see docs for more.
* '''Contact''' - mcote, glob, smacleod
* '''Inputs'''
** BMO
** reviewboard-hg.mozilla.org
* '''Outputs/Services'''
** BMO
** Various repositories via Autoland

=== OrangeFactor ===

* '''Docs''' - [[Auto-tools/Projects/OrangeFactor]]
* '''Code''' - https://hg.mozilla.org/automation/orangefactor/
* '''Contact''' - :jgriffin, :mcote
* '''Inputs'''
** buildbot messages (using pulse)
** build logs
** comments from TBPL
** bugzilla bug data
* '''Outputs/Services'''
** https://brasstacks.mozilla.com/orangefactor/
** email status [War on Orange]

=== Ouija ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Ouija
* '''Code''' - https://github.com/dminor/ouija.git
* '''Contact''' - dminor, jmaher
* '''Inputs'''
** https://hg.mozilla.org/
** tbpl.mozilla.org
* '''Outputs/Services'''
** http://54.215.155.53

=== Perfherder ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/Perfherder
* '''Code''' - https://github.com/mozilla/treeherder/tree/master/treeherder/perf
* '''Contact''' - :wlach
* '''Inputs'''
** PERFHERDER_DATA
*** schema https://github.com/mozilla/treeherder/blob/master/schemas/performance-artifact.json
*** example http://wrla.ch/blog/2015/11/perfherder-onward/
* '''Outputs/Services'''
** https://treeherder.mozilla.org/perf.html#/graphs

=== Pulse ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Pulse
* '''Code''' - development library: https://hg.mozilla.org/automation/mozillapulse
* '''Contact''' - mcote
* '''Inputs'''
** a multitude of other systems
* '''Outputs/Services'''
** a multitude of other systems
** https://pulse.mozilla.org/

=== PulseGuardian ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Pulse/PulseGuardian
* '''Code''' - https://github.com/mozilla/pulseguardian/
* '''Contact''' - mcote
* '''Inputs'''
** Persona (for auth) (soon to be Okta or TaskCluster auth)
** Pulse
** Web UI
* '''Outputs/Services'''
** Pulse
** Email notifications

=== PulseTranslator ===
* '''Docs''' - https://github.com/mozilla/pulsetranslator/blob/master/README.md
* '''Code''' - https://github.com/mozilla/pulsetranslator
* '''Contact''' - jgriffin@mozilla.com
* '''Inputs'''
** Pulse exchange/build
* '''Outputs/Services'''
** Pulse exchange/build/normalized

=== Structured Logging ===
* '''Docs''' - https://mozbase.readthedocs.org/en/latest/loggingreporting.html, https://wiki.mozilla.org/Auto-tools/Projects/Structured_Logging
* '''Contacts''' - [:chmanchester][:ahal][:jgraham]

=== Talos ===
* '''Docs''' - https://wiki.mozilla.org/Buildbot/Talos
* '''Code''' - https://hg.mozilla.org/build/talos
* '''Contact''' - jmaher@mozilla.com
* '''Inputs'''
** build for desktop or android
** commandline (done via mozharness now) to specify which test(s) to run
* '''Outputs/Services'''
** log file with raw data
** uploaded summarization of data to graph server
** uploaded raw data to datazilla

Can be referred to as what is run by buildbot or by tbpl since this is the only performance test run on our per revision CI system. Other tools are run at a different cadence.

=== TBPL (retired) ===

* '''Docs''' - [[Sheriffing/TBPL]]
* '''Code''' - https://hg.mozilla.org/webtools/tbpl/
* '''Contact''' - [[Sheriffing/TBPL#Developer_Contacts]]
* '''Inputs'''
**
* '''Outputs/Services'''
**

=== Test Informant ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Test-Informant
* '''Code''' - See project page
* '''Contact''' - [:ahal]
* '''Inputs'''
** build notifications via pulse
** test manifests in tests.zip
* '''Outputs'''
** reports at e.g., http://brasstacks.mozilla.com/testreports/weekly

=== Treeherder ===
* '''Docs''' - [[Auto-tools/Projects/Treeherder]]
* '''Code''' - [[Auto-tools/Projects/Treeherder#Source_and_Docs]]
* '''Contact''' - [:camd][:mdoglio][:edmorley]
* '''Inputs'''
** Pushlog from hg.mozilla.org via json-pushes
** Build/tests from Buildbot via buildapi
** Direct pushes via ``treeherder-client``
** Build/tests from Taskcluster (under development)
* '''Outputs/Services'''
** https://treeherder.mozilla.org/
** https://treeherder.mozilla.org/api/

=== web-platform-tests ===
* '''Docs''' - https://wptrunner.readthedocs.org/en/latest/, Needs project page?
* '''Code'''
** https://github.com/w3c/web-platform-tests/
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/README.md
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/tests/README.md
* '''Contact''' - [:jgraham]

== Example ==

Use the EMPTY TEMPLATE to add more entries. Include ones you know about, even if you can not fill them.

=== EXAMPLE ===
* '''Docs''' - some wiki, or read the docs to learn more
* '''Code''' - link to code, if it makes sense
* '''Contact''' - for ekyle to contact if he has questions
* '''Inputs''' -
** automated resources
** services consumed
* '''Outputs/Services'''
** automated services provided
** dashboards (and teams that consume them)

=== EMPTY TEMPLATE ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
**

EngineeringProductivity/Meetings

2016-09-19T19:08:06Z

Klahnakoski: mention cancelled meetings so ekyle does not get confused

== Dial-in information ==
# This meeting will start at [http://www.timeanddate.com/worldclock/fixedtime.html?iso=20111107T10&p1=283 10AM PDT]
# Guest: https://v.mozilla.com/flex.html?roomdirect.html&key=43kzfyP8BDSG
# Vidyo: A-Team Vidyo Room
# Phone: 650-903-0800 or 650-215-1282 x92 Conf# 98416 (US/INTL)
# 1-800-707-2533 (pin 369) Conf# 98416 (free for anyone to join)
# IRC: irc://irc.mozilla.org:6697/#ateam

== Meeting Notes ==

Templates:
* 2015: [[auto-tools/Meetings/goals_meeting_template2015Q1|Q1]] / [[EngineeringProductivity/Meetings/goals_meeting_template2015Q3|Q3]] / [[EngineeringProductivity/Meetings/goals_meeting_template2015Q4|Q4]]
* 2014: [[auto-tools/Meetings/goals_meeting_template2014Q1|Q1]] / [[auto-tools/Meetings/goals_meeting_template2014Q2|Q2]] / [[auto-tools/Meetings/goals_meeting_template2014Q3|Q3]] / [[auto-tools/Meetings/goals_meeting_template2014Q4|Q4]]
* 2013: [[auto-tools/Meetings/goals_meeting_template2013Q1|Q1]] / [[auto-tools/Meetings/goals_meeting_template2013Q2|Q2]] / [[auto-tools/Meetings/goals_meeting_template2013Q3|Q3]]
* 2012: [[auto-tools/Meetings/goals_meeting_template|Q2]] / [[auto-tools/Meetings/goals_meeting_template2012Q3|Q3]] / [[auto-tools/Meetings/goals_meeting_template2012Q4|Q4]]
* 2011: [[auto-tools/Meetings/template|Q4]] / [[auto-tools/Meetings/new_template|Nov]]

Create a new weekly agenda from the [[EngineeringProductivity/Meetings/goals_meeting_template2015Q4|2015Q4 template]]:

<createbox>
align=left
type=create
preload=EngineeringProductivity/Meetings/goals_meeting_template2015Q4
default={{#time: Y-m-d}}
prefix=EngineeringProductivity/Meetings/
</createbox>

{| class="wikitable collapsible" style="width: 100%"
! 2016
|-
|
* [[EngineeringProductivity/Meetings/2016-09-19|Sep 19 2016]]
* [[EngineeringProductivity/Meetings/2016-09-05|Sep 05 2016]] - cancelled due to Labor Day
* [[EngineeringProductivity/Meetings/2016-08-22|Aug 22 2016]]
* [[EngineeringProductivity/Meetings/2016-08-08|Aug 08 2016]]
* [[EngineeringProductivity/Meetings/2016-07-25|Jul 25 2016]] - cancelled due to Town Hall
* [[EngineeringProductivity/Meetings/2016-07-11|Jul 11 2016]]
* [[EngineeringProductivity/Meetings/2016-06-27|Jun 27 2016]]
* [[EngineeringProductivity/Meetings/2016-06-06|Jun 06 2016]]
* [[EngineeringProductivity/Meetings/2016-05-16|May 16 2016]]
* [[EngineeringProductivity/Meetings/2016-05-02|May 02 2016]]
* [[EngineeringProductivity/Meetings/2016-04-18|Apr 18 2016]]
* [[EngineeringProductivity/Meetings/2016-04-04|Apr 04 2016]]
* [[EngineeringProductivity/Meetings/2016-03-21|Mar 21 2016]]
* [[EngineeringProductivity/Meetings/2016-03-07|Mar 07 2016]]
* [[EngineeringProductivity/Meetings/2016-02-22|Feb 22 2016]]
* Feb 08 2016 - Cancelled
* [[EngineeringProductivity/Meetings/2016-01-25|Jan 25 2016]]
* [[EngineeringProductivity/Meetings/2016-01-11|Jan 11 2016]]
|}

{| class="wikitable collapsible" style="width: 100%"
! 2015
|-
|
* [[EngineeringProductivity/Meetings/2015-12-21|Dec 21 2015]]
* [[EngineeringProductivity/Meetings/2015-11-30|Nov 30 2015]]
* [[EngineeringProductivity/Meetings/2015-11-16|Nov 16 2015]]
* [[EngineeringProductivity/Meetings/2015-11-02|Nov 02 2015]]
* [[EngineeringProductivity/Meetings/2015-10-19|Oct 19 2015]]
* [[EngineeringProductivity/Meetings/2015-10-05|Oct 05 2015]]
* [[EngineeringProductivity/Meetings/2015-09-21|Sep 21 2015]]
* [[EngineeringProductivity/Meetings/2015-09-14|Sep 14 2015]]
* Sep 7 2015 - no meeting, due to US and Canadian holidays
* [[Auto-tools/Meetings/2015-08-24|Aug 24 2015]]
* [[Auto-tools/Meetings/2015-08-10|Aug 10 2015]]
* [[Auto-tools/Meetings/2015-07-27|Jul 27 2015]]
* [[Auto-tools/Meetings/2015-07-13|Jul 13 2015]]
* [[Auto-tools/Meetings/2015-07-06|Jul 06 2015]]
* [[Auto-tools/Meetings/2015-06-15|Jun 15 2015]]
* [[Auto-tools/Meetings/2015-06-01|Jun 01 2015]]
* [[Auto-tools/Meetings/2015-05-18|May 18 2015]]
* [[Auto-tools/Meetings/2015-05-04|May 04 2015]]
* [[Auto-tools/Meetings/2015-04-20|Apr 20 2015]]
* [[Auto-tools/Meetings/2015-04-06|Apr 06 2015]]
* [[Auto-tools/Meetings/2015-03-23|Mar 23 2015]]
* [[Auto-tools/Meetings/2015-03-09|Mar 09 2015]]
* [[Auto-tools/Meetings/2015-02-23|Feb 23 2015]]
* [[Auto-tools/Meetings/2015-02-09|Feb 09 2015]]
* [[Auto-tools/Meetings/2015-01-26|Jan 26 2015]]
* [[Auto-tools/Meetings/2015-01-12|Jan 12 2015]]
* [[Auto-tools/Meetings/2015-01-05|Jan 05 2015]]
|}

{| class="wikitable collapsible autocollapse" style="width: 100%"
! 2014
|-
|
* [[Auto-tools/Meetings/2014-12-22|Dec 22 2014]]
* [[Auto-tools/Meetings/2014-12-15|Dec 15 2014]]
* [[Auto-tools/Meetings/2014-11-24|Nov 24 2014]]
* [[Auto-tools/Meetings/2014-11-10|Nov 10 2014]]
* [[Auto-tools/Meetings/2014-10-27|Oct 27 2014]]
* [[Auto-tools/Meetings/2014-10-20|Oct 20 2014]]
* [[Auto-tools/Meetings/2014-09-29|Sep 29 2014]]
* [[Auto-tools/Meetings/2014-09-15|Sep 15 2014]]
* [[Auto-tools/Meetings/2014-09-08|Sep 08 2014]]
* [[Auto-tools/Meetings/2014-08-18|Aug 18 2014]]
* [[Auto-tools/Meetings/2014-08-04|Aug 04 2014]]
* [[Auto-tools/Meetings/2014-07-21|Jul 21 2014]]
* [[Auto-tools/Meetings/2014-07-07|Jul 07 2014]]
* [[Auto-tools/Meetings/2014-06-23|Jun 23 2014]]
* [[Auto-tools/Meetings/2014-06-09|Jun 09 2014]]
* [[Auto-tools/Meetings/2014-06-02|Jun 02 2014]]
* [[Auto-tools/Meetings/2014-05-12|May 12 2014]]
* [[Auto-tools/Meetings/2014-04-28|Apr 28 2014]]
* [[Auto-tools/Meetings/2014-04-14|Apr 14 2014]]
* [[Auto-tools/Meetings/2014-03-31|Mar 31 2014]]
* [[Auto-tools/Meetings/2014-03-17|Mar 17 2014]]
* [[Auto-tools/Meetings/2014-03-03|Mar 03 2014]]
* [[Auto-tools/Meetings/2014-02-24|Feb 24 2014]]
* [[Auto-tools/Meetings/2014-02-03|Feb 03 2014]]
* [[Auto-tools/Meetings/2014-01-06|Jan 06 2014]]
|}

{| class="wikitable collapsible autocollapse" style="width: 100%"
! 2013
|-
|
* [[Auto-tools/Meetings/2013-12-16|Dec 16 2013]]
* [[Auto-tools/Meetings/2013-12-02|Dec 02 2013]]
* [[Auto-tools/Meetings/2013-11-25|Nov 25 2013]]
* [[Auto-tools/Meetings/2013-11-18|Nov 18 2013]]
* [[Auto-tools/Meetings/2013-11-11|Nov 11 2013]]
* [[Auto-tools/Meetings/2013-11-04|Nov 4 2013]]
* [[Auto-tools/Meetings/2013-10-28|Oct 28 2013]]
* [[Auto-tools/Meetings/2013-10-21|Oct 21 2013]]
* [[Auto-tools/Meetings/2013-10-14|Oct 14 2013]]
* [[Auto-tools/Meetings/2013-09-30|Sept 30 2013]]
* [[Auto-tools/Meetings/2013-09-23|Sept 23 2013]]
* [[Auto-tools/Meetings/2013-09-16|Sept 16 2013]]
* [[Auto-tools/Meetings/2013-09-09|Sept 9 2013]]
* Sept 2 2013 - canceled due to US Holiday
* [[Auto-tools/Meetings/2013-08-26|Aug 26 2013]]
* [[Auto-tools/Meetings/2013-08-19|Aug 19 2013]]
* [[Auto-tools/Meetings/2013-08-12|Aug 12 2013]]
* [[Auto-tools/Meetings/2013-07-29|Jul 29 2013]]
* [[Auto-tools/Meetings/2013-07-22|Jul 22 2013]]
* [[Auto-tools/Meetings/2013-07-15|Jul 15 2013]]
* [[Auto-tools/Meetings/2013-07-08|Jul 08 2013]]
* [[Auto-tools/Meetings/2013-07-01|Jul 01 2013]]
* [[Auto-tools/Meetings/2013-06-24|Jun 24 2013]]
* [[Auto-tools/Meetings/2013-06-17|Jun 17 2013]]
* [[Auto-tools/Meetings/2013-06-10|Jun 10 2013]]
* [[Auto-tools/Meetings/2013-06-03|Jun 03 2013]]
* [[Auto-tools/Meetings/2013-05-27|May 27 2013]]
* [[Auto-tools/Meetings/2013-05-20|May 20 2013]]
* [[Auto-tools/Meetings/2013-05-13|May 13 2013]]
* [[Auto-tools/Meetings/2013-05-06|May 06 2013]]
* [[Auto-tools/Meetings/2013-04-29|Apr 29 2013]]
* [[Auto-tools/Meetings/2013-04-22|Apr 22 2013]]
* [[Auto-tools/Meetings/2013-04-15|Apr 15 2013]]
* [[Auto-tools/Meetings/2013-04-08|Apr 08 2013]]
* [[Auto-tools/Meetings/2013-04-01|Apr 01 2013]]
* [[Auto-tools/Meetings/2013-03-25|Mar 25 2013]]
* [[Auto-tools/Meetings/2013-03-18|Mar 18 2013]]
* [[Auto-tools/Meetings/2013-03-11|Mar 11 2013]]
* [[Auto-tools/Meetings/2013-03-04|Mar 04 2013]]
* [[Auto-tools/Meetings/2013-02-25|Feb 25 2013]]
* [[Auto-tools/Meetings/2013-02-11|Feb 11 2013]]
* [[Auto-tools/Meetings/2013-02-04|Feb 04 2013]]
* [[Auto-tools/Meetings/2013-01-28|Jan 28 2013]]
* [[Auto-tools/Meetings/2013-01-21|Jan 21 2013]]
* [[Auto-tools/Meetings/2013-01-14|Jan 14 2013]]
* [[Auto-tools/Meetings/2013-01-07|Jan 7 2013]]
|}

{| class="wikitable collapsible autocollapse" style="width: 100%"
! 2012
|-
|
* [[Auto-tools/Meetings/2012-12-17|Dec 17 2012]]
* [[Auto-tools/Meetings/2012-12-10|Dec 10 2012]]
* [[Auto-tools/Meetings/2012-12-03|Dec 03 2012]]
* [[Auto-tools/Meetings/2012-11-26|Nov 26 2012]]
* [[Auto-tools/Meetings/2012-11-19|Nov 19 2012]]
* [[Auto-tools/Meetings/2012-11-12|Nov 12 2012]]
* [[Auto-tools/Meetings/2012-11-05|Nov 05 2012]]
* [[Auto-tools/Meetings/2012-10-29|Oct 29 2012]]
* [[Auto-tools/Meetings/2012-10-22|Oct 22 2012]]
* [[Auto-tools/Meetings/2012-10-15|Oct 15 2012]]
* [[Auto-tools/Meetings/2012-10-08|Oct 08 2012]]
* [[Auto-tools/Meetings/2012-10-01|Oct 01 2012]]
* [[auto-tools/Meetings/2012-09-24|Sep 24 2012]]
* [[auto-tools/Meetings/2012-09-17|Sep 17 2012]]
* [[auto-tools/Meetings/2012-09-10|Sep 10 2012]] (mc: mdas)
* [[auto-tools/Meetings/2012-09-03|Sep 03 2012]] (No one since US/Cananda Holiday, just updates)
* [[auto-tools/Meetings/2012-08-27|Aug 27 2012]] (mc: tbc)
* [[auto-tools/Meetings/2012-08-20|Aug 20 2012]] (mc: davehunt)
* [[auto-tools/Meetings/2012-08-13|Aug 13 2012]] (mc: dkl)
* [[auto-tools/Meetings/2012-08-06|Aug 06 2012]] (mc: jhammel)
* [[auto-tools/Meetings/2012-07-30|Jul 30 2012]] (mc: mcote)
* [[auto-tools/Meetings/2012-07-23|Jul 23 2012]] (mc: ted)
* [[auto-tools/Meetings/2012-07-16|Jul 16 2012]] (mc: ctalbert)
* [[auto-tools/Meetings/2012-07-09|Jul 09 2012]] (mc: jeads)
* [[auto-tools/Meetings/2012-07-02|Jul 02 2012]] (mc: carljm)
* [[auto-tools/Meetings/2012-06-25|Jun 25 2012]] (mc: ahal)
* [[auto-tools/Meetings/2012-06-18|Jun 18 2012]] (mc: mcote)
* [[auto-tools/Meetings/2012-06-11|Jun 11 2012]] (mc: jgriffin)
* [[auto-tools/Meetings/2012-06-04|Jun 04 2012]] (mc: ctalbert)
* [[auto-tools/Meetings/2012-05-28|May 28 2012]] (no meeting due to US holiday)
* [[auto-tools/Meetings/2012-05-21|May 21 2012]] (mc: camd)
* [[auto-tools/Meetings/2012-05-14|May 14 2012]] (mc: dburns)
* [[auto-tools/Meetings/2012-05-07|May 07 2012]] (mc: ctalbert)
* [[auto-tools/Meetings/2012-04-30|Apr 30 2012]] (mc: mdas)
* [[auto-tools/Meetings/2012-04-23|Apr 23 2012]] (mc: bc)
* [[auto-tools/Meetings/2012-04-16|Apr 16 2012]] (mc: wlach)
* [[auto-tools/Meetings/2012-04-09|Apr 09 2012]]
* [[auto-tools/Meetings/2012-04-02|Apr 02 2012]]
* [[auto-tools/Meetings/2012-03-26|Mar 26 2012]]
* [[auto-tools/Meetings/2012-03-19|Mar 19 2012]] (mc: jmaher)
* [[auto-tools/Meetings/2012-03-12|Mar 12 2012]]
* [[auto-tools/Meetings/2012-03-05|Mar 05 2012]]
* [[auto-tools/Meetings/2012-02-27|Feb 27 2012]]
* [[auto-tools/Meetings/2012-02-13|Feb 13 2012]]
* [[auto-tools/Meetings/2012-02-06|Feb 06 2012]]
* [[auto-tools/Meetings/2012-01-30|Jan 30 2012]]
* [[auto-tools/Meetings/2012-01-23|Jan 23 2012]]
* Jan 17th canceled due to US holiday
* [[auto-tools/Meetings/2012-01-09|Jan 09 2012]]
|}

{| class="wikitable collapsible autocollapse" style="width: 100%"
! 2011
|-
|
* [[auto-tools/Meetings/2011-12-19|Dec 19 2011]]
* [[auto-tools/Meetings/2011-12-12|Dec 12 2011]]
* [[auto-tools/Meetings/2011-12-05|Dec 05 2011]]
* [[auto-tools/Meetings/2011-11-28|Nov 28 2011]]
* [[auto-tools/Meetings/2011-11-21|Nov 21 2011]]
* [[auto-tools/Meetings/2011-11-14|Nov 14 2011]]
* [[auto-tools/Meetings/2011-11-07|Nov 7 2011]]
* [[auto-tools/Meetings/2011-10-31|Oct 31 2011]]
* [[auto-tools/Meetings/2011-10-24|Oct 24 2011]]
* [[auto-tools/Meetings/2011-10-17|Oct 17 2011]]
* [[auto-tools/Meetings/2011-10-10|Oct 10 2011]]
* [[auto-tools/Meetings/2011-10-03|Oct 03 2011]]
* [[auto-tools/Meetings/2011-09-26|Sep 26 2011]]
* [[auto-tools/Meetings/2011-08-29|Aug 29 2011]]
* [[auto-tools/Meetings/2011-08-22|Aug 22 2011]]
* [[auto-tools/Meetings/2011-08-15|Aug 15 2011]]
* [[auto-tools/Meetings/2011-08-08|Aug 08 2011]]
* [[auto-tools/Meetings/2011-08-01|Aug 01 2011]]
* [[auto-tools/Meetings/2011-07-25|Jul 25 2011]]
* [[auto-tools/Meetings/2011-07-18|Jul 18 2011]]
* [[auto-tools/Meetings/2011-07-11|Jul 11 2011]]
* July 4th canceled due to US holiday
* [[auto-tools/Meetings/2011-06-27|Jun 27 2011]]
* [[auto-tools/Meetings/2011-06-20|Jun 20 2011]]
* [[auto-tools/Meetings/2011-06-13|Jun 13 2011]]
* [[auto-tools/Meetings/2011-06-06|Jun 06 2011]]
* May 30 canceled due to US holiday
* [[auto-tools/Meetings/2011-05-23|May 23 2011]]
* [[auto-tools/Meetings/2011-05-16|May 16 2011]]
* [[auto-tools/Meetings/2011-05-09|May 09 2011]]
* [[auto-tools/Meetings/2011-05-02|May 02 2011]]
* [[auto-tools/Meetings/2011-04-25|Apr 25 2011]]
* [[auto-tools/Meetings/2011-04-18|Apr 18 2011]]
* [[auto-tools/Meetings/2011-04-11|Apr 11 2011]]
* Apr 4 canceled due to all hands
* [[auto-tools/Meetings/2011-03-28|Mar 28 2011]]
* [[auto-tools/Meetings/2011-03-21|Mar 21 2011]]
* [[auto-tools/Meetings/2011-03-14|Mar 14 2011]]
* [[auto-tools/Meetings/2011-03-07|Mar 07 2011]]
* [[auto-tools/Meetings/2011-02-28|Feb 28 2011]]
* Feb 21 canceled due to holiday
* [[auto-tools/Meetings/2011-02-14|Feb 14 2011]]
* [[auto-tools/Meetings/2011-02-07|Feb 07 2011]]
* [[auto-tools/Meetings/2011-01-31|Jan 31 2011]]
* [[auto-tools/Meetings/2011-01-24|Jan 24 2011]]
* Jan 17 2011, no meeting, US holiday
* [[auto-tools/Meetings/2011-01-10|Jan 10 2011]]
* [[auto-tools/Meetings/2011-01-03|Jan 03 2011]]
|}

{| class="wikitable collapsible autocollapse" style="width: 100%"
! 2010
|-
|
* [[auto-tools/Meetings/2010-12-27|Dec 27 2010]]
* [[auto-tools/Meetings/2010-12-20|Dec 20 2010]]
* Dec 13 2010 - no meeting, all hands
* [[auto-tools/Meetings/2010-12-06|Dec 06 2010]]
* [[auto-tools/Meetings/2010-11-29|Nov 29 2010]]
* [[auto-tools/Meetings/2010-11-22|Nov 22 2010]]
* [[auto-tools/Meetings/2010-11-15|Nov 15 2010]]
* [[auto-tools/Meetings/2010-11-08|Nov 08 2010]]
* [[auto-tools/Meetings/2010-11-01|Nov 01 2010]]
* [[auto-tools/Meetings/2010-10-25|Oct 25 2010]]
* [[auto-tools/Meetings/2010-10-18|Oct 18 2010]]
* [[auto-tools/Meetings/2010-10-11|Oct 11 2010]]
* [[auto-tools/Meetings/2010-10-04|Oct 04 2010]]
* [[auto-tools/Meetings/2010-09-27|Sept 27 2010]]
* [[auto-tools/Meetings/2010-09-20|Sept 20 2010]]
* [[auto-tools/Meetings/2010-09-13|Sept 13 2010]]
* Sept 6 canceled due to holiday
* [[auto-tools/Meetings/2010-08-30|Aug 30 2010]]
* [[auto-tools/Meetings/2010-08-23|Aug 23 2010]]
* [[auto-tools/Meetings/2010-08-16|Aug 16 2010]]
* [[auto-tools/Meetings/2010-08-09|Aug 09 2010]]
* [[auto-tools/Meetings/2010-08-02|Aug 02 2010]]
* [[auto-tools/Meetings/2010-07-26|Jul 26 2010]]
* [[auto-tools/Meetings/2010-07-19|Jul 19 2010]]
* [[auto-tools/Meetings/2010-07-12|Jul 12 2010]]
* <strike>July 5 2010</strike> (Canceled due to US Holiday & Mozilla Summit)
* [[auto-tools/Meetings/2010-06-28|Jun 28 2010]]
* [[auto-tools/Meetings/2010-06-21|Jun 21 2010]]
* [[auto-tools/Meetings/2010-06-14|Jun 14 2010]]
* [[auto-tools/Meetings/2010-06-07|Jun 07 2010]]
* <strike>May 31 2010</strike> (Canceled due to US Holiday)
* [[auto-tools/Meetings/2010-05-24|May 24 2010]]
* [[auto-tools/Meetings/2010-05-17|May 17 2010]]
* [[auto-tools/Meetings/2010-05-10|May 10 2010]]
* [[auto-tools/Meetings/2010-05-03|May 03 2010]]
* [[auto-tools/Meetings/2010-04-26|Apr 26 2010]]
* [[auto-tools/Meetings/2010-04-19|Apr 19 2010]]
* [[auto-tools/Meetings/2010-04-12|Apr 12 2010]]
* [[auto-tools/Meetings/2010-04-05|Apr 05 2010]]
* [[QA/TDAI/MeetingNotes/2010-03-29|Mar 29 2010]]
* [[QA/TDAI/MeetingNotes/2010-03-22|Mar 22 2010]]
* [[QA/TDAI/MeetingNotes/2010-03-15|Mar 15 2010]]
* [[QA/TDAI/MeetingNotes/2010-03-08|Mar 08 2010]]
* [[QA/TDAI/MeetingNotes/2010-03-01|Mar 01 2010]]
* [[QA/TDAI/MeetingNotes/2010-02-22|Feb 22 2010]]
* [[QA/TDAI/MeetingNotes/2010-02-08|Feb 08 2010]]
* [[QA/TDAI/MeetingNotes/2010-02-01|Feb 01 2010]]
* [[QA/TDAI/MeetingNotes/2010-01-25|Jan 25 2010]]
* [[QA/TDAI/MeetingNotes/2010-01-11|Jan 11 2010]]
* [[QA/TDAI/MeetingNotes/2010-01-04|Jan 04 2010]]
|}

{| class="wikitable collapsible autocollapse" style="width: 100%"
! 2009
|-
|
* [[QA/TDAI/MeetingNotes/2009-12-28|Dec 28 2009]]
* [[QA/TDAI/MeetingNotes/2009-12-21|Dec 21 2009]]
* [[QA/TDAI/MeetingNotes/2009-11-23|Nov 23 2009]]
* [[QA/TDAI/MeetingNotes/2009-11-02|Nov 02 2009]]
* [[QA/TDAI/MeetingNotes/2009-10-19|Oct 19 2009]]
* [[QA/TDAI/MeetingNotes/2009-10-12|Oct 12 2009]]
* [[QA/TDAI/MeetingNotes/2009-10-05|Oct 05 2009]]
* [[QA/TDAI/MeetingNotes/2009-09-28|Sept 28 2009]]
* [[QA/TDAI/MeetingNotes/2009-09-21|Sept 21 2009]]
* [[QA/TDAI/MeetingNotes/2009-09-14|Sept 14 2009]]
* [[QA/TDAI/MeetingNotes/2009-08-31|Aug 31 2009]]
* [[QA/TDAI/MeetingNotes/2009-08-24|Aug 24 2009]]
|}

EngineeringProductivity/Projects/Everything

2016-09-12T14:25:03Z

Klahnakoski: add schema

== Project Table ==

The project table has been moved to https://wiki.mozilla.org/EngineeringProductivity/Projects

== Motivation ==

This page is to help diagram all the various things the A*Team has built and continue to support.

The plan is to draw high level components/systems, and links between them, so it is easier to see how all the parts work together. Hopefully this diagram will be clickable so the reader can get more detail on each of the components.

Something like [https://wiki.mozilla.org/images/f/f3/Releng_flow_onepage_treeclose_reasons.pdf what RelEng has], but without all the internals.

''Template can be found below''

== The List ==

=== ActiveData ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
* '''Code''' - https://github.com/klahnakoski/ActiveData
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Buildbot JSON logs
** hg.mozilla.org
** OrangeFactor
** Perfherder
** Pulse exchange/build/normalized
** Structured Logs from Tests
** Talos
** Text logs (for buildbot and mozharness steps only)
* '''Outputs/Services'''
** Query endpoint: http://activedata.allizom.org/query
** Query Tool: http://activedata.allizom.org/tools/query.html

=== AlertManager ===

* '''Docs''' -https://github.com/jmaher/alert_manager/
* '''Code''' - https://github.com/jmaher/alert_manager/
* '''Contact' - jmaher@mozilla.com
* '''Inputs'''
** mozilla.dev.tree-management alerts from graph server
* '''Outputs/Services'''
** webUI for organizing and taking action on these alerts.

=== Autoland ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Autoland
* '''Code''' - https://github.com/dminor/autoland
* '''Contact''' - [:dminor]
* '''Inputs'''
** try jobs via pulse
** job status via relengapi
* '''Outputs'''
** autoland comments posted to bugzilla
** patches landed via releng's 'hg transplant'

=== Autophone ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/AutoPhone
* '''Code''' - https://github.com/mozilla/autophone/
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
** http://phonedash.mozilla.org/ (used by who?)

=== Bugzilla ===
* '''Docs''' - https://bugzilla.readthedocs.org
* '''Code''' - https://git.mozilla.org/?p=webtools/bmo/bugzilla.git
* '''Contact''' - Mark Cote, Byron Jones, David Lawrence, Dylan Hardison
* '''Inputs'''
** Web UI
** WebServices API (REST, XMLRPC, JSONRPC)
* '''Outputs/Services'''
** https://bugzilla.mozilla.org (bug reporters, developers, etc)
** WebServices API (For REST https://bugzilla.mozilla.org/rest)

=== BugzFeed ===
* '''Docs''' - [[BMO/ChangeNotificationSystem]]
* '''Code''' - https://github.com/mozilla/bugzfeed
* '''Contact''' - mcote@mozilla.com
* '''Inputs'''
** BMO via [[Auto-tools/Projects/Pulse|Pulse]]
* '''Outputs/Services'''
** WebSocket servers:
*** bugzfeed.mozilla.org
*** bugzfeed-dev.allizom.org

=== Bugzilla/ES Cluster ===

* '''Docs''' - https://wiki.mozilla.org/BMO/ElasticSearch
* '''Code''' - https://github.com/klahnakoski/Bugzilla-ETL
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** Bugzilla (direct database access)
* '''Outputs/Services'''
** https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version

=== Buildbot ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
** hg.mozilla.org
* '''Outputs/Services'''
** builder slaves
** tester slaves
** https://wiki.mozilla.org/ReleaseEngineering/BuildAPI ??
** JSON Logs: http://builddata.pub.build.mozilla.org/builddata/buildjson/

=== C++ Code Coverage ===

* '''Docs''' - https://bugzilla.mozilla.org/show_bug.cgi?id=890116
* '''Contact''' - [:ahal]
* Used to be possible to trigger code coverage builds with 'try: -b o -p linux64-cc -u all -t none', but I think this is broken now. Probably isn't terribly hard to revive this. Needs further investigation.

=== charts.mozilla.org ===

* '''Docs''' -
* '''Code''' - https://github.com/mozilla/charts
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** BMO/ES Cluster (https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version)
* '''Outputs/Services'''
** http://charts.mozilla.org (for management)

=== CodeCoverage ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/CodeCoverage
* '''Code'''
** '''UI''' - https://github.com/chinhodado/codecoverage_presenter
** '''ETL''' - https://github.com/klahnakoski/ActiveData-ETL/blob/dev/activedata_etl/transforms/jscov_to_es.py
* '''Contact''' - jmaher@mozilla.com, klahnakoski@mozilla.com, chmanchester@mozilla.com
* '''Inputs'''
** Various tests have been configured with a code coverage option
* '''Outputs/Services'''
** ActiveData - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
** http://chinhodado.github.io/codecoverage_presenter/

=== Datazilla (retired) ===

* '''Docs''' - https://datazilla.readthedocs.org/en/latest/
* '''Code''' - https://datazilla.readthedocs.org/en/latest/
* '''Contact''' - See Treeherder
* '''Inputs'''
** data pushed from Talos (see Graph Server)
* '''Outputs/Services'''
** charts at https://datazilla.mozilla.org
** raw results at https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob

=== DevelopmentMetrics ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/DevelopmentMetrics
* '''Code''' - https://github.com/klahnakoski/MoDevMetrics
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Bugzilla/ES Cluster
* '''Outputs/Services'''
** various charts and dashboards

=== DevTools Harness ===

* '''Docs''' - Needs project page!
* '''Contact''' - [:ted.mielczarek]

=== dzAlerts (retired)===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Alerts
* '''Code''' - https://github.com/klahnakoski/datazilla-alerts
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Datazilla web service (https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob)
** Eideticket web service (http://eideticker.mozilla.org)
* '''Outputs/Services'''
** fxos-perf-alerts@mozilla.org (b2g sheriffs?)

=== Eideticker ===

* '''Docs''' - https://wiki.mozilla.org/Project_Eideticker#Documentation
* '''Code''' - https://github.com/mozilla/eideticker
* '''Contact''' - William Lachance, Dave Hunt
* '''Inputs'''
** Nightly/inbound b2g and android builds.
* '''Outputs/Services'''
** Eideticker dashboard (http://eideticker.mozilla.org)

=== m21s ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/m21s
* '''Code''' - see project page
* '''Contacts''' - [:chmanchester][:ahal][:whimboo]
* '''Inputs'''
** Mozmill release tests
* '''Outputs'''
** 'Firefox Greenlight Tests' in Marionette, reporting to Treeherder

=== Marionette ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Marionette
* '''Code''' -
* '''Contact''' - [:AutomatedTester][:ato]
* '''What''' - Mozilla's native WebDriver implementation

=== Mozharness ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Mozharness
* '''Code''' - https://hg.mozilla.org/build/mozharness/
* '''Contact''' - [:armenzg]
* '''Inputs'''
** command-line invocation via buildbot or locally
* '''Outputs/Services'''
** build/test logs consumed by buildbot, Treeherder, TBPL

=== MozReview (Review Board) ===
* '''Docs''' - [[Auto-tools/Projects/CodeReviewTool]]
* '''Code''' - various pieces of https://hg.mozilla.org/hgcustom/version-control-tools; see docs for more.
* '''Contact''' - mcote@mozilla.com
* '''Inputs'''
** BMO
** hg.mozilla.org
* '''Outputs/Services'''
** BMO

=== OrangeFactor ===

* '''Docs''' - [[Auto-tools/Projects/OrangeFactor]]
* '''Code''' - https://hg.mozilla.org/automation/orangefactor/
* '''Contact''' - :jgriffin, :mcote
* '''Inputs'''
** buildbot messages (using pulse)
** build logs
** comments from TBPL
** bugzilla bug data
* '''Outputs/Services'''
** https://brasstacks.mozilla.com/orangefactor/
** email status [War on Orange]

=== Ouija ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Ouija
* '''Code''' - https://github.com/dminor/ouija.git
* '''Contact''' - dminor, jmaher
* '''Inputs'''
** https://hg.mozilla.org/
** tbpl.mozilla.org
* '''Outputs/Services'''
** http://54.215.155.53

=== Perfherder ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/Perfherder
* '''Code''' - https://github.com/mozilla/treeherder/tree/master/treeherder/perf
* '''Contact''' - :wlach
* '''Inputs'''
** PERFHERDER_DATA
*** schema https://github.com/mozilla/treeherder/blob/master/schemas/performance-artifact.json
*** example http://wrla.ch/blog/2015/11/perfherder-onward/
* '''Outputs/Services'''
** https://treeherder.mozilla.org/perf.html#/graphs

=== Pulse ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Pulse
* '''Code''' - https://hg.mozilla.org/automation/mozillapulse
* '''Contact''' - Mark Côté
* '''Inputs''' (exchanges? http://christian.legnitto.com/blog/2010/07/17/mozilla-pulse-and-rabbitmq/)
** a multitude of other systems
* '''Outputs/Services'''
** a multitude of other systems
** https://pulse.mozilla.org/

=== PulseTranslator ===
* '''Docs''' - https://github.com/mozilla/pulsetranslator/blob/master/README.md
* '''Code''' - https://github.com/mozilla/pulsetranslator
* '''Contact''' - jgriffin@mozilla.com
* '''Inputs'''
** Pulse exchange/build
* '''Outputs/Services'''
** Pulse exchange/build/normalized

=== Structured Logging ===
* '''Docs''' - https://mozbase.readthedocs.org/en/latest/loggingreporting.html, https://wiki.mozilla.org/Auto-tools/Projects/Structured_Logging
* '''Contacts''' - [:chmanchester][:ahal][:jgraham]

=== Talos ===
* '''Docs''' - https://wiki.mozilla.org/Buildbot/Talos
* '''Code''' - https://hg.mozilla.org/build/talos
* '''Contact''' - jmaher@mozilla.com
* '''Inputs'''
** build for desktop or android
** commandline (done via mozharness now) to specify which test(s) to run
* '''Outputs/Services'''
** log file with raw data
** uploaded summarization of data to graph server
** uploaded raw data to datazilla

Can be referred to as what is run by buildbot or by tbpl since this is the only performance test run on our per revision CI system. Other tools are run at a different cadence.

=== TBPL (retired) ===

* '''Docs''' - [[Sheriffing/TBPL]]
* '''Code''' - https://hg.mozilla.org/webtools/tbpl/
* '''Contact''' - [[Sheriffing/TBPL#Developer_Contacts]]
* '''Inputs'''
**
* '''Outputs/Services'''
**

=== Test Informant ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Test-Informant
* '''Code''' - See project page
* '''Contact''' - [:ahal]
* '''Inputs'''
** build notifications via pulse
** test manifests in tests.zip
* '''Outputs'''
** reports at e.g., http://brasstacks.mozilla.com/testreports/weekly

=== Treeherder ===
* '''Docs''' - [[Auto-tools/Projects/Treeherder]]
* '''Code''' - [[Auto-tools/Projects/Treeherder#Source_and_Docs]]
* '''Contact''' - [:camd][:mdoglio][:edmorley]
* '''Inputs'''
** Pushlog from hg.mozilla.org via json-pushes
** Build/tests from Buildbot via buildapi
** Direct pushes via ``treeherder-client``
** Build/tests from Taskcluster (under development)
* '''Outputs/Services'''
** https://treeherder.mozilla.org/
** https://treeherder.mozilla.org/api/

=== web-platform-tests ===
* '''Docs''' - https://wptrunner.readthedocs.org/en/latest/, Needs project page?
* '''Code'''
** https://github.com/w3c/web-platform-tests/
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/README.md
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/tests/README.md
* '''Contact''' - [:jgraham]

== Example ==

Use the EMPTY TEMPLATE to add more entries. Include ones you know about, even if you can not fill them.

=== EXAMPLE ===
* '''Docs''' - some wiki, or read the docs to learn more
* '''Code''' - link to code, if it makes sense
* '''Contact''' - for ekyle to contact if he has questions
* '''Inputs''' -
** automated resources
** services consumed
* '''Outputs/Services'''
** automated services provided
** dashboards (and teams that consume them)

=== EMPTY TEMPLATE ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
**

EngineeringProductivity/Projects/Everything

2016-09-12T13:14:11Z

Klahnakoski: "retired"

== Project Table ==

The project table has been moved to https://wiki.mozilla.org/EngineeringProductivity/Projects

== Motivation ==

This page is to help diagram all the various things the A*Team has built and continue to support.

The plan is to draw high level components/systems, and links between them, so it is easier to see how all the parts work together. Hopefully this diagram will be clickable so the reader can get more detail on each of the components.

Something like [https://wiki.mozilla.org/images/f/f3/Releng_flow_onepage_treeclose_reasons.pdf what RelEng has], but without all the internals.

''Template can be found below''

== The List ==

=== ActiveData ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
* '''Code''' - https://github.com/klahnakoski/ActiveData
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Buildbot JSON logs
** hg.mozilla.org
** OrangeFactor
** Perfherder
** Pulse exchange/build/normalized
** Structured Logs from Tests
** Talos
** Text logs (for buildbot and mozharness steps only)
* '''Outputs/Services'''
** Query endpoint: http://activedata.allizom.org/query
** Query Tool: http://activedata.allizom.org/tools/query.html

=== AlertManager ===

* '''Docs''' -https://github.com/jmaher/alert_manager/
* '''Code''' - https://github.com/jmaher/alert_manager/
* '''Contact' - jmaher@mozilla.com
* '''Inputs'''
** mozilla.dev.tree-management alerts from graph server
* '''Outputs/Services'''
** webUI for organizing and taking action on these alerts.

=== Autoland ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Autoland
* '''Code''' - https://github.com/dminor/autoland
* '''Contact''' - [:dminor]
* '''Inputs'''
** try jobs via pulse
** job status via relengapi
* '''Outputs'''
** autoland comments posted to bugzilla
** patches landed via releng's 'hg transplant'

=== Autophone ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/AutoPhone
* '''Code''' - https://github.com/mozilla/autophone/
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
** http://phonedash.mozilla.org/ (used by who?)

=== Bugzilla ===
* '''Docs''' - https://bugzilla.readthedocs.org
* '''Code''' - https://git.mozilla.org/?p=webtools/bmo/bugzilla.git
* '''Contact''' - Mark Cote, Byron Jones, David Lawrence, Dylan Hardison
* '''Inputs'''
** Web UI
** WebServices API (REST, XMLRPC, JSONRPC)
* '''Outputs/Services'''
** https://bugzilla.mozilla.org (bug reporters, developers, etc)
** WebServices API (For REST https://bugzilla.mozilla.org/rest)

=== BugzFeed ===
* '''Docs''' - [[BMO/ChangeNotificationSystem]]
* '''Code''' - https://github.com/mozilla/bugzfeed
* '''Contact''' - mcote@mozilla.com
* '''Inputs'''
** BMO via [[Auto-tools/Projects/Pulse|Pulse]]
* '''Outputs/Services'''
** WebSocket servers:
*** bugzfeed.mozilla.org
*** bugzfeed-dev.allizom.org

=== Bugzilla/ES Cluster ===

* '''Docs''' - https://wiki.mozilla.org/BMO/ElasticSearch
* '''Code''' - https://github.com/klahnakoski/Bugzilla-ETL
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** Bugzilla (direct database access)
* '''Outputs/Services'''
** https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version

=== Buildbot ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
** hg.mozilla.org
* '''Outputs/Services'''
** builder slaves
** tester slaves
** https://wiki.mozilla.org/ReleaseEngineering/BuildAPI ??
** JSON Logs: http://builddata.pub.build.mozilla.org/builddata/buildjson/

=== C++ Code Coverage ===

* '''Docs''' - https://bugzilla.mozilla.org/show_bug.cgi?id=890116
* '''Contact''' - [:ahal]
* Used to be possible to trigger code coverage builds with 'try: -b o -p linux64-cc -u all -t none', but I think this is broken now. Probably isn't terribly hard to revive this. Needs further investigation.

=== charts.mozilla.org ===

* '''Docs''' -
* '''Code''' - https://github.com/mozilla/charts
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** BMO/ES Cluster (https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version)
* '''Outputs/Services'''
** http://charts.mozilla.org (for management)

=== CodeCoverage ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/CodeCoverage
* '''Code'''
** '''UI''' - https://github.com/chinhodado/codecoverage_presenter
** '''ETL''' - https://github.com/klahnakoski/ActiveData-ETL/blob/dev/activedata_etl/transforms/jscov_to_es.py
* '''Contact''' - jmaher@mozilla.com, klahnakoski@mozilla.com, chmanchester@mozilla.com
* '''Inputs'''
** Various tests have been configured with a code coverage option
* '''Outputs/Services'''
** ActiveData - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
** http://chinhodado.github.io/codecoverage_presenter/

=== Datazilla (retired) ===

* '''Docs''' - https://datazilla.readthedocs.org/en/latest/
* '''Code''' - https://datazilla.readthedocs.org/en/latest/
* '''Contact''' - See Treeherder
* '''Inputs'''
** data pushed from Talos (see Graph Server)
* '''Outputs/Services'''
** charts at https://datazilla.mozilla.org
** raw results at https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob

=== DevelopmentMetrics ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/DevelopmentMetrics
* '''Code''' - https://github.com/klahnakoski/MoDevMetrics
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Bugzilla/ES Cluster
* '''Outputs/Services'''
** various charts and dashboards

=== DevTools Harness ===

* '''Docs''' - Needs project page!
* '''Contact''' - [:ted.mielczarek]

=== dzAlerts (retired)===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Alerts
* '''Code''' - https://github.com/klahnakoski/datazilla-alerts
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Datazilla web service (https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob)
** Eideticket web service (http://eideticker.mozilla.org)
* '''Outputs/Services'''
** fxos-perf-alerts@mozilla.org (b2g sheriffs?)

=== Eideticker ===

* '''Docs''' - https://wiki.mozilla.org/Project_Eideticker#Documentation
* '''Code''' - https://github.com/mozilla/eideticker
* '''Contact''' - William Lachance, Dave Hunt
* '''Inputs'''
** Nightly/inbound b2g and android builds.
* '''Outputs/Services'''
** Eideticker dashboard (http://eideticker.mozilla.org)

=== m21s ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/m21s
* '''Code''' - see project page
* '''Contacts''' - [:chmanchester][:ahal][:whimboo]
* '''Inputs'''
** Mozmill release tests
* '''Outputs'''
** 'Firefox Greenlight Tests' in Marionette, reporting to Treeherder

=== Marionette ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Marionette
* '''Code''' -
* '''Contact''' - [:AutomatedTester][:ato]
* '''What''' - Mozilla's native WebDriver implementation

=== Mozharness ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Mozharness
* '''Code''' - https://hg.mozilla.org/build/mozharness/
* '''Contact''' - [:armenzg]
* '''Inputs'''
** command-line invocation via buildbot or locally
* '''Outputs/Services'''
** build/test logs consumed by buildbot, Treeherder, TBPL

=== MozReview (Review Board) ===
* '''Docs''' - [[Auto-tools/Projects/CodeReviewTool]]
* '''Code''' - various pieces of https://hg.mozilla.org/hgcustom/version-control-tools; see docs for more.
* '''Contact''' - mcote@mozilla.com
* '''Inputs'''
** BMO
** hg.mozilla.org
* '''Outputs/Services'''
** BMO

=== OrangeFactor ===

* '''Docs''' - [[Auto-tools/Projects/OrangeFactor]]
* '''Code''' - https://hg.mozilla.org/automation/orangefactor/
* '''Contact''' - :jgriffin, :mcote
* '''Inputs'''
** buildbot messages (using pulse)
** build logs
** comments from TBPL
** bugzilla bug data
* '''Outputs/Services'''
** https://brasstacks.mozilla.com/orangefactor/
** email status [War on Orange]

=== Ouija ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Ouija
* '''Code''' - https://github.com/dminor/ouija.git
* '''Contact''' - dminor, jmaher
* '''Inputs'''
** https://hg.mozilla.org/
** tbpl.mozilla.org
* '''Outputs/Services'''
** http://54.215.155.53

=== Perfherder ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/Perfherder
* '''Code''' - https://github.com/mozilla/treeherder/tree/master/treeherder/perf
* '''Contact''' - :wlach
* '''Inputs'''
** PERFHERDER_DATA: see format http://wrla.ch/blog/2015/11/perfherder-onward/
* '''Outputs/Services'''
** https://treeherder.mozilla.org/perf.html#/graphs

=== Pulse ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Pulse
* '''Code''' - https://hg.mozilla.org/automation/mozillapulse
* '''Contact''' - Mark Côté
* '''Inputs''' (exchanges? http://christian.legnitto.com/blog/2010/07/17/mozilla-pulse-and-rabbitmq/)
** a multitude of other systems
* '''Outputs/Services'''
** a multitude of other systems
** https://pulse.mozilla.org/

=== PulseTranslator ===
* '''Docs''' - https://github.com/mozilla/pulsetranslator/blob/master/README.md
* '''Code''' - https://github.com/mozilla/pulsetranslator
* '''Contact''' - jgriffin@mozilla.com
* '''Inputs'''
** Pulse exchange/build
* '''Outputs/Services'''
** Pulse exchange/build/normalized

=== Structured Logging ===
* '''Docs''' - https://mozbase.readthedocs.org/en/latest/loggingreporting.html, https://wiki.mozilla.org/Auto-tools/Projects/Structured_Logging
* '''Contacts''' - [:chmanchester][:ahal][:jgraham]

=== Talos ===
* '''Docs''' - https://wiki.mozilla.org/Buildbot/Talos
* '''Code''' - https://hg.mozilla.org/build/talos
* '''Contact''' - jmaher@mozilla.com
* '''Inputs'''
** build for desktop or android
** commandline (done via mozharness now) to specify which test(s) to run
* '''Outputs/Services'''
** log file with raw data
** uploaded summarization of data to graph server
** uploaded raw data to datazilla

Can be referred to as what is run by buildbot or by tbpl since this is the only performance test run on our per revision CI system. Other tools are run at a different cadence.

=== TBPL (retired) ===

* '''Docs''' - [[Sheriffing/TBPL]]
* '''Code''' - https://hg.mozilla.org/webtools/tbpl/
* '''Contact''' - [[Sheriffing/TBPL#Developer_Contacts]]
* '''Inputs'''
**
* '''Outputs/Services'''
**

=== Test Informant ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Test-Informant
* '''Code''' - See project page
* '''Contact''' - [:ahal]
* '''Inputs'''
** build notifications via pulse
** test manifests in tests.zip
* '''Outputs'''
** reports at e.g., http://brasstacks.mozilla.com/testreports/weekly

=== Treeherder ===
* '''Docs''' - [[Auto-tools/Projects/Treeherder]]
* '''Code''' - [[Auto-tools/Projects/Treeherder#Source_and_Docs]]
* '''Contact''' - [:camd][:mdoglio][:edmorley]
* '''Inputs'''
** Pushlog from hg.mozilla.org via json-pushes
** Build/tests from Buildbot via buildapi
** Direct pushes via ``treeherder-client``
** Build/tests from Taskcluster (under development)
* '''Outputs/Services'''
** https://treeherder.mozilla.org/
** https://treeherder.mozilla.org/api/

=== web-platform-tests ===
* '''Docs''' - https://wptrunner.readthedocs.org/en/latest/, Needs project page?
* '''Code'''
** https://github.com/w3c/web-platform-tests/
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/README.md
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/tests/README.md
* '''Contact''' - [:jgraham]

== Example ==

Use the EMPTY TEMPLATE to add more entries. Include ones you know about, even if you can not fill them.

=== EXAMPLE ===
* '''Docs''' - some wiki, or read the docs to learn more
* '''Code''' - link to code, if it makes sense
* '''Contact''' - for ekyle to contact if he has questions
* '''Inputs''' -
** automated resources
** services consumed
* '''Outputs/Services'''
** automated services provided
** dashboards (and teams that consume them)

=== EMPTY TEMPLATE ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
**

EngineeringProductivity/Meetings/2016-09-19

2016-09-12T13:13:23Z

Klahnakoski: add plead for updating Everything

= Notices, Highlights, Roundtable =
* Significant Contributions

= Newsgroup and Blog Posts =

= Goal Updates =

Please update https://docs.google.com/spreadsheets/d/16eSZlITqgjxkDZmrykfVJjU_OltSnvH090ULvSeMU6I/edit#gid=1272068002 with the status of your Q4 deliverables.

Also see our [https://trello.com/b/3BjXQCEp/a-team-projects Trello board]

= Other Project Updates =

= Holidays and Trips =

= Misc =

* [ekyle] Please update Everything with your high level project specs: https://wiki.mozilla.org/EngineeringProductivity/Projects/Everything

Auto-tools/Projects/ActiveData

2016-09-12T13:09:12Z

Klahnakoski: Klahnakoski moved page Auto-tools/Projects/ActiveData to EngineeringProductivity/Projects/ActiveData: Team name change

#REDIRECT [[EngineeringProductivity/Projects/ActiveData]]

EngineeringProductivity/Projects/ActiveData

2016-09-12T13:09:03Z

Klahnakoski: Klahnakoski moved page Auto-tools/Projects/ActiveData to EngineeringProductivity/Projects/ActiveData: Team name change

= Overview =

ActiveData is a collection of about 8 billion records (Feb 2016) covering unit tests, Buildbot jobs, performance data, and mercurial. This collection is publicly available, and can be queried directly, similar to any database.

ActiveData is built on top of ElasticSearch, a fast, distributed, redundant document store. ActiveData provides the benefits of familiar and succinct SQL by translating SQL-like queries to ElasticSearch queries,

== Problem ==
In order to improve our testing infrastructure we require data on how that infrastructure is performing. That information can be extracted from the raw logs, but that requires downloading samples, parsing data, insertion into a database (or worse, writing queries in an imperative language, like Python). When we are done an analysis we have effectively built an ETL pipeline that does not scale, and is too specific to be reused elsewhere. The next project does this work all over again.

== Solution==
ActiveData will serve as a reusable ETL pipeline; annotating the test results with as much relevant data as possible. It also provides a query service to explore and aggregate the data, so there is minimal setup required to access this data.

= Charts =

ActiveData is fast enough to support dashboards.

== Build times ==
{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/Builds-Overview.html Build Times]
|| Time series view of build times by platform and build type. Click on a bar to get a scatter plot view.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/Builds-Detail.html Detailed Build Times]
|| Scatter plot of build times. Use the left navigation panel to choose a combination. Click on a data point to see the Buildbot step times and Mozharness step times.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/Buildbot-Simulator.html Buildbot Simulator] incomplete
|| An incomplete Buildbot scheduling simulator. It can be used to see past wait times, queue size, and inter-job delays.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/index.html Test Runtimes]
|| Choose test suite and machine pool to get an average run time for each of the buildbot steps, and Mozharness steps.
|}

==Unit Test Visualization==
With all unit test results in ActiveData, we can get accurate estimates of "failure rate"; and be able to focus on the most-failing tests.

{| class="wikitable"
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/testfailures/ Top Intermittent Failures]
|| List of top 30 most-failing unit tests, and list of top 30 most-recent failing tests. Click on the link to get a scatterplot.
|-
| style="vertical-align:top;width:300px;" | [http://people.mozilla.org/~klahnakoski/testfailures/test.html Find Test Results]
|| Use the search bar to find a test. A list of matching tests, and platform combinations will show the unit test failures and durations.
|}

= Design =
ActiveData attempts to provide the benefits of an available database to the public; except larger and faster.

== Goals ==
An active data instance distinguishes itself from a static resource, or database, or big data solution, by delivering a particular set of features:
* '''A service, open to third party clients''' - By providing the service, clients don't need to setup their own datastore
* '''Fast filtering''' - Sub-second filtering over the contents of the whole datastore, independent of size, saves the application developer from declaring and managing indexes that do the same: There is sufficient information in the queries to determine which indexes should be built to deliver a quick response.
* '''Fast aggregates''' - Sub-second calculation of statistics over the whole datastore saves the application developer from building and managing caches of those aggregates.
* '''API is a query language (SQL?, MDX?)''' - Building upon the formalisms, and familiarity, of existing query languages, we reduce the learning curve, and also provide Active Data implementations with more insight into the intent of the client application; and optimize for its use cases.
* '''Uniform, Cartesian space of values''' - Mozilla has a mandate of data driven decision making. Data analysis tools, like Spreadsheets, R, Scipy, Numpy, and Pandas are used to perform data analysis, and they all require uniform data in multi-dimensional arrays, commonly known as "pivot tables" or "data frames". ActiveData's objective is to provide query results in these formats
* '''Metadata on dimensions and measures''' - ActiveData also provides context to the data it holds. It serves the purpose to allow exploration and discovery by third parties; by describing unit-of-measure, how dimensions relate to others, and provide human descriptions of the columns stored. This metadata is also invaluable in automating the orientation and formatting of dashboard charts: Knowing the domain of an axis allows code to decide the best (default) chart form, and provides logically reasonable aggregate options.
* '''Has a security model''' - Simpler applications can avoid the complications of a security model if it is baked into the ActiveData solution. If ActiveData is to become mainstream it is important that it can manage sensitive data and PII.

== Limitations ==

The unittest data is limited to those test suites that generate structured logs. Currently (Feb, 2016) the following do NOT have structured logs, and are NOT in ActiveData:

* cppunittest
* and any of the js based gaia suites (e.g Gij)

Specifically, you can see if a structured log is being generated: In Treeherder, click a job. Under the "Job details" pane at the bottom, look for a line similar to:

<blockquote> ''artifact uploaded: <suite>_raw.log''
</blockquote>

If you see that, it is using structured logging.

ActiveData makes specific tradeoffs to achieve its goals. It has the following limitations:
* large memory requirements
* low add/update/remove speeds
* strict data model (snowflake schema, hierarchical relations only)
* non-relational
* ETL work required to de-normalize data
* ETL work required to provide dimension metadata

== Non Goals ==
ActiveData is not meant to replace an application database. Applications often track significantly more data related to good interface design, process sequences, complex relations, and object life cycles.
ActiveData's simple model makes it difficult to track object life cycles and impossible to model many-to-many relations.
Data is not live, and definitely does not track "pending jobs" like TreeHerder or TaskCluster do. Test results may take a day, or more, to be indexed.

= Dependencies / Who will use this =
== Dependencies ==

ActiveData's ETL pipeline ingests data from a variety of sources:

* Buildbot
* Mozharness
* Structured Logs
* Task Cluster (end of Q1 2016)
* PerfHerder
* hg.mozilla.org

== Users ==

ActiveData's primary goal is to support dashboards that give Mozilla useful perspectives into the large amount of data:

* Individual unit test results
* Buildbot test times
* Firefox compile times
* Recently new, removed, and disabled tests
* Buildbot wait times

= Let's Use It! =

The service listens at http://activedata.allizom.org/query and accepts queries in [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md JSON Query Expression format].

curl -XPOST -d "{\"from\":\"unittest\"}" http://activedata.allizom.org/query

== The Query Tool ==
The ActiveData service is intended for use by automated clients, not humans. The [http://activedata.allizom.org/tools/query.html Query Tool] is a minimal web page for humans to do some exploration, and to test phrasing queries.
* [http://activedata.allizom.org/tools/query.html ActiveData QueryTool]

== Documentation ==
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/jx_tutorial.md tutorial]
* [https://github.com/klahnakoski/ActiveData/blob/dev/docs/Unittest%20Schema.md Unit test results schema]

= Code =
Development is still in the early stages, setting up your own service
* Github: https://github.com/klahnakoski/ActiveData
== Tests ==
* [https://github.com/klahnakoski/ActiveData/blob/master/tests/test_unittests.py testing code which sends some unittest-specific queries]

== Bugs ==
Bug are tracked in [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=activedata Bugzilla]. The open issues are shown here:
<bugzilla>
{
"quicksearch":"activedata"
}
</bugzilla>

= Contact =

* Kyle Lahnakoski
** IRC: ekyle@irc.mozilla.org
** Email: klahnakoski@mozilla.org
** Bugzilla: :ekyle

= More Context=
Mostly rambling, optional reading.

== Inspiration==
This project is inspired by the data warehouse and data mart technology that is common inside large corporations. These warehouses are useful because they are "active" services: This means the data is not only available, but it can be explored interactively by large audience using a query language.

== General Problem ==
A significant portion of any application is the backend database/datastore, which include:
* Managing resources and machines to support the datastore
* Data migrations on schemas during application lifetime
* Manually defining database indexes for responsive data retrieval
* Coding caching logic to reduce application latency

The manual effort put toward these features becomes significant as the amount of data grows in size and complexity. More importantly, this effort is being spent over and over on a multitude of applications, each a trivial variation of the next.

==General Solution==

Abstractly, we desire to reduce this redundant workload by adding a layer of abstraction called ActiveData: Clients using ActiveData benefit from the features it provides and avoid the datastore management complexities. While the ActiveData implementers can focus on these common issues while being given a simpler data model, and simpler query language, upon which to calculate optimizations.

Columnar datastores, have solved many (but not all) problems with changing schema. Query-directed indexing has been around for decades in Oracle's query optimization algorithms, and are available for free in ElasticSearch. We now have the technology to build an ActiveData solution.

By defining an ActiveData standard, we can innovate on both sides of the ActiveData abstraction layer independently

== Client Architecture ==

Applications that leverage an active data warehouse can forgo significant server side development, if not all, and put the logic on the client side.

Auto-tools/Projects/Everything

2016-09-12T13:06:16Z

Klahnakoski: Klahnakoski moved page Auto-tools/Projects/Everything to EngineeringProductivity/Projects/Everything: Team name change

#REDIRECT [[EngineeringProductivity/Projects/Everything]]

EngineeringProductivity/Projects/Everything

2016-09-12T13:06:07Z

Klahnakoski: Klahnakoski moved page Auto-tools/Projects/Everything to EngineeringProductivity/Projects/Everything: Team name change

== Project Table ==

The project table has been moved to https://wiki.mozilla.org/EngineeringProductivity/Projects

== Motivation ==

This page is to help diagram all the various things the A*Team has built and continue to support.

The plan is to draw high level components/systems, and links between them, so it is easier to see how all the parts work together. Hopefully this diagram will be clickable so the reader can get more detail on each of the components.

Something like [https://wiki.mozilla.org/images/f/f3/Releng_flow_onepage_treeclose_reasons.pdf what RelEng has], but without all the internals.

''Template can be found below''

== The List ==

=== ActiveData ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
* '''Code''' - https://github.com/klahnakoski/ActiveData
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Buildbot JSON logs
** hg.mozilla.org
** OrangeFactor
** Perfherder
** Pulse exchange/build/normalized
** Structured Logs from Tests
** Talos
** Text logs (for buildbot and mozharness steps only)
* '''Outputs/Services'''
** Query endpoint: http://activedata.allizom.org/query
** Query Tool: http://activedata.allizom.org/tools/query.html

=== AlertManager ===

* '''Docs''' -https://github.com/jmaher/alert_manager/
* '''Code''' - https://github.com/jmaher/alert_manager/
* '''Contact' - jmaher@mozilla.com
* '''Inputs'''
** mozilla.dev.tree-management alerts from graph server
* '''Outputs/Services'''
** webUI for organizing and taking action on these alerts.

=== Autoland ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Autoland
* '''Code''' - https://github.com/dminor/autoland
* '''Contact''' - [:dminor]
* '''Inputs'''
** try jobs via pulse
** job status via relengapi
* '''Outputs'''
** autoland comments posted to bugzilla
** patches landed via releng's 'hg transplant'

=== Autophone ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/AutoPhone
* '''Code''' - https://github.com/mozilla/autophone/
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
** http://phonedash.mozilla.org/ (used by who?)

=== Bugzilla ===
* '''Docs''' - https://bugzilla.readthedocs.org
* '''Code''' - https://git.mozilla.org/?p=webtools/bmo/bugzilla.git
* '''Contact''' - Mark Cote, Byron Jones, David Lawrence, Dylan Hardison
* '''Inputs'''
** Web UI
** WebServices API (REST, XMLRPC, JSONRPC)
* '''Outputs/Services'''
** https://bugzilla.mozilla.org (bug reporters, developers, etc)
** WebServices API (For REST https://bugzilla.mozilla.org/rest)

=== BugzFeed ===
* '''Docs''' - [[BMO/ChangeNotificationSystem]]
* '''Code''' - https://github.com/mozilla/bugzfeed
* '''Contact''' - mcote@mozilla.com
* '''Inputs'''
** BMO via [[Auto-tools/Projects/Pulse|Pulse]]
* '''Outputs/Services'''
** WebSocket servers:
*** bugzfeed.mozilla.org
*** bugzfeed-dev.allizom.org

=== Bugzilla/ES Cluster ===

* '''Docs''' - https://wiki.mozilla.org/BMO/ElasticSearch
* '''Code''' - https://github.com/klahnakoski/Bugzilla-ETL
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** Bugzilla (direct database access)
* '''Outputs/Services'''
** https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version

=== Buildbot ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
** hg.mozilla.org
* '''Outputs/Services'''
** builder slaves
** tester slaves
** https://wiki.mozilla.org/ReleaseEngineering/BuildAPI ??
** JSON Logs: http://builddata.pub.build.mozilla.org/builddata/buildjson/

=== C++ Code Coverage ===

* '''Docs''' - https://bugzilla.mozilla.org/show_bug.cgi?id=890116
* '''Contact''' - [:ahal]
* Used to be possible to trigger code coverage builds with 'try: -b o -p linux64-cc -u all -t none', but I think this is broken now. Probably isn't terribly hard to revive this. Needs further investigation.

=== charts.mozilla.org ===

* '''Docs''' -
* '''Code''' - https://github.com/mozilla/charts
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** BMO/ES Cluster (https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version)
* '''Outputs/Services'''
** http://charts.mozilla.org (for management)

=== CodeCoverage ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/CodeCoverage
* '''Code'''
** '''UI''' - https://github.com/chinhodado/codecoverage_presenter
** '''ETL''' - https://github.com/klahnakoski/ActiveData-ETL/blob/dev/activedata_etl/transforms/jscov_to_es.py
* '''Contact''' - jmaher@mozilla.com, klahnakoski@mozilla.com, chmanchester@mozilla.com
* '''Inputs'''
** Various tests have been configured with a code coverage option
* '''Outputs/Services'''
** ActiveData - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
** http://chinhodado.github.io/codecoverage_presenter/

=== Datazilla (retired) ===

* '''Docs''' - https://datazilla.readthedocs.org/en/latest/
* '''Code''' - https://datazilla.readthedocs.org/en/latest/
* '''Contact''' - See Treeherder
* '''Inputs'''
** data pushed from Talos (see Graph Server)
* '''Outputs/Services'''
** charts at https://datazilla.mozilla.org
** raw results at https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob

=== DevelopmentMetrics ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/DevelopmentMetrics
* '''Code''' - https://github.com/klahnakoski/MoDevMetrics
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Bugzilla/ES Cluster
* '''Outputs/Services'''
** various charts and dashboards

=== DevTools Harness ===

* '''Docs''' - Needs project page!
* '''Contact''' - [:ted.mielczarek]

=== dzAlerts (retired)===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Alerts
* '''Code''' - https://github.com/klahnakoski/datazilla-alerts
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Datazilla web service (https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob)
** Eideticket web service (http://eideticker.mozilla.org)
* '''Outputs/Services'''
** fxos-perf-alerts@mozilla.org (b2g sheriffs?)

=== Eideticker ===

* '''Docs''' - https://wiki.mozilla.org/Project_Eideticker#Documentation
* '''Code''' - https://github.com/mozilla/eideticker
* '''Contact''' - William Lachance, Dave Hunt
* '''Inputs'''
** Nightly/inbound b2g and android builds.
* '''Outputs/Services'''
** Eideticker dashboard (http://eideticker.mozilla.org)

=== m21s ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/m21s
* '''Code''' - see project page
* '''Contacts''' - [:chmanchester][:ahal][:whimboo]
* '''Inputs'''
** Mozmill release tests
* '''Outputs'''
** 'Firefox Greenlight Tests' in Marionette, reporting to Treeherder

=== Marionette ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Marionette
* '''Code''' -
* '''Contact''' - [:AutomatedTester][:ato]
* '''What''' - Mozilla's native WebDriver implementation

=== Mozharness ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Mozharness
* '''Code''' - https://hg.mozilla.org/build/mozharness/
* '''Contact''' - [:armenzg]
* '''Inputs'''
** command-line invocation via buildbot or locally
* '''Outputs/Services'''
** build/test logs consumed by buildbot, Treeherder, TBPL

=== MozReview (Review Board) ===
* '''Docs''' - [[Auto-tools/Projects/CodeReviewTool]]
* '''Code''' - various pieces of https://hg.mozilla.org/hgcustom/version-control-tools; see docs for more.
* '''Contact''' - mcote@mozilla.com
* '''Inputs'''
** BMO
** hg.mozilla.org
* '''Outputs/Services'''
** BMO

=== OrangeFactor ===

* '''Docs''' - [[Auto-tools/Projects/OrangeFactor]]
* '''Code''' - https://hg.mozilla.org/automation/orangefactor/
* '''Contact''' - :jgriffin, :mcote
* '''Inputs'''
** buildbot messages (using pulse)
** build logs
** comments from TBPL
** bugzilla bug data
* '''Outputs/Services'''
** https://brasstacks.mozilla.com/orangefactor/
** email status [War on Orange]

=== Ouija ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Ouija
* '''Code''' - https://github.com/dminor/ouija.git
* '''Contact''' - dminor, jmaher
* '''Inputs'''
** https://hg.mozilla.org/
** tbpl.mozilla.org
* '''Outputs/Services'''
** http://54.215.155.53

=== Perfherder ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/Perfherder
* '''Code''' - https://github.com/mozilla/treeherder/tree/master/treeherder/perf
* '''Contact''' - :wlach
* '''Inputs'''
** PERFHERDER_DATA: see format http://wrla.ch/blog/2015/11/perfherder-onward/
* '''Outputs/Services'''
** https://treeherder.mozilla.org/perf.html#/graphs

=== Pulse ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Pulse
* '''Code''' - https://hg.mozilla.org/automation/mozillapulse
* '''Contact''' - Mark Côté
* '''Inputs''' (exchanges? http://christian.legnitto.com/blog/2010/07/17/mozilla-pulse-and-rabbitmq/)
** a multitude of other systems
* '''Outputs/Services'''
** a multitude of other systems
** https://pulse.mozilla.org/

=== PulseTranslator ===
* '''Docs''' - https://github.com/mozilla/pulsetranslator/blob/master/README.md
* '''Code''' - https://github.com/mozilla/pulsetranslator
* '''Contact''' - jgriffin@mozilla.com
* '''Inputs'''
** Pulse exchange/build
* '''Outputs/Services'''
** Pulse exchange/build/normalized

=== Structured Logging ===
* '''Docs''' - https://mozbase.readthedocs.org/en/latest/loggingreporting.html, https://wiki.mozilla.org/Auto-tools/Projects/Structured_Logging
* '''Contacts''' - [:chmanchester][:ahal][:jgraham]

=== Talos ===
* '''Docs''' - https://wiki.mozilla.org/Buildbot/Talos
* '''Code''' - https://hg.mozilla.org/build/talos
* '''Contact''' - jmaher@mozilla.com
* '''Inputs'''
** build for desktop or android
** commandline (done via mozharness now) to specify which test(s) to run
* '''Outputs/Services'''
** log file with raw data
** uploaded summarization of data to graph server
** uploaded raw data to datazilla

Can be referred to as what is run by buildbot or by tbpl since this is the only performance test run on our per revision CI system. Other tools are run at a different cadence.

=== TBPL (for the sake of history) ===

* '''Docs''' - [[Sheriffing/TBPL]]
* '''Code''' - https://hg.mozilla.org/webtools/tbpl/
* '''Contact''' - [[Sheriffing/TBPL#Developer_Contacts]]
* '''Inputs'''
**
* '''Outputs/Services'''
**

=== Test Informant ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Test-Informant
* '''Code''' - See project page
* '''Contact''' - [:ahal]
* '''Inputs'''
** build notifications via pulse
** test manifests in tests.zip
* '''Outputs'''
** reports at e.g., http://brasstacks.mozilla.com/testreports/weekly

=== Treeherder ===
* '''Docs''' - [[Auto-tools/Projects/Treeherder]]
* '''Code''' - [[Auto-tools/Projects/Treeherder#Source_and_Docs]]
* '''Contact''' - [:camd][:mdoglio][:edmorley]
* '''Inputs'''
** Pushlog from hg.mozilla.org via json-pushes
** Build/tests from Buildbot via buildapi
** Direct pushes via ``treeherder-client``
** Build/tests from Taskcluster (under development)
* '''Outputs/Services'''
** https://treeherder.mozilla.org/
** https://treeherder.mozilla.org/api/

=== web-platform-tests ===
* '''Docs''' - https://wptrunner.readthedocs.org/en/latest/, Needs project page?
* '''Code'''
** https://github.com/w3c/web-platform-tests/
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/README.md
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/tests/README.md
* '''Contact''' - [:jgraham]

== Example ==

Use the EMPTY TEMPLATE to add more entries. Include ones you know about, even if you can not fill them.

=== EXAMPLE ===
* '''Docs''' - some wiki, or read the docs to learn more
* '''Code''' - link to code, if it makes sense
* '''Contact''' - for ekyle to contact if he has questions
* '''Inputs''' -
** automated resources
** services consumed
* '''Outputs/Services'''
** automated services provided
** dashboards (and teams that consume them)

=== EMPTY TEMPLATE ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
**

EngineeringProductivity/Projects/Everything

2016-09-12T12:59:44Z

Klahnakoski: add perfherder!!!

== Project Table ==

The project table has been moved to https://wiki.mozilla.org/EngineeringProductivity/Projects

== Motivation ==

This page is to help diagram all the various things the A*Team has built and continue to support.

The plan is to draw high level components/systems, and links between them, so it is easier to see how all the parts work together. Hopefully this diagram will be clickable so the reader can get more detail on each of the components.

Something like [https://wiki.mozilla.org/images/f/f3/Releng_flow_onepage_treeclose_reasons.pdf what RelEng has], but without all the internals.

''Template can be found below''

== The List ==

=== ActiveData ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
* '''Code''' - https://github.com/klahnakoski/ActiveData
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Buildbot JSON logs
** hg.mozilla.org
** OrangeFactor
** Perfherder
** Pulse exchange/build/normalized
** Structured Logs from Tests
** Talos
** Text logs (for buildbot and mozharness steps only)
* '''Outputs/Services'''
** Query endpoint: http://activedata.allizom.org/query
** Query Tool: http://activedata.allizom.org/tools/query.html

=== AlertManager ===

* '''Docs''' -https://github.com/jmaher/alert_manager/
* '''Code''' - https://github.com/jmaher/alert_manager/
* '''Contact' - jmaher@mozilla.com
* '''Inputs'''
** mozilla.dev.tree-management alerts from graph server
* '''Outputs/Services'''
** webUI for organizing and taking action on these alerts.

=== Autoland ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Autoland
* '''Code''' - https://github.com/dminor/autoland
* '''Contact''' - [:dminor]
* '''Inputs'''
** try jobs via pulse
** job status via relengapi
* '''Outputs'''
** autoland comments posted to bugzilla
** patches landed via releng's 'hg transplant'

=== Autophone ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/AutoPhone
* '''Code''' - https://github.com/mozilla/autophone/
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
** http://phonedash.mozilla.org/ (used by who?)

=== Bugzilla ===
* '''Docs''' - https://bugzilla.readthedocs.org
* '''Code''' - https://git.mozilla.org/?p=webtools/bmo/bugzilla.git
* '''Contact''' - Mark Cote, Byron Jones, David Lawrence, Dylan Hardison
* '''Inputs'''
** Web UI
** WebServices API (REST, XMLRPC, JSONRPC)
* '''Outputs/Services'''
** https://bugzilla.mozilla.org (bug reporters, developers, etc)
** WebServices API (For REST https://bugzilla.mozilla.org/rest)

=== BugzFeed ===
* '''Docs''' - [[BMO/ChangeNotificationSystem]]
* '''Code''' - https://github.com/mozilla/bugzfeed
* '''Contact''' - mcote@mozilla.com
* '''Inputs'''
** BMO via [[Auto-tools/Projects/Pulse|Pulse]]
* '''Outputs/Services'''
** WebSocket servers:
*** bugzfeed.mozilla.org
*** bugzfeed-dev.allizom.org

=== Bugzilla/ES Cluster ===

* '''Docs''' - https://wiki.mozilla.org/BMO/ElasticSearch
* '''Code''' - https://github.com/klahnakoski/Bugzilla-ETL
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** Bugzilla (direct database access)
* '''Outputs/Services'''
** https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version

=== Buildbot ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
** hg.mozilla.org
* '''Outputs/Services'''
** builder slaves
** tester slaves
** https://wiki.mozilla.org/ReleaseEngineering/BuildAPI ??
** JSON Logs: http://builddata.pub.build.mozilla.org/builddata/buildjson/

=== C++ Code Coverage ===

* '''Docs''' - https://bugzilla.mozilla.org/show_bug.cgi?id=890116
* '''Contact''' - [:ahal]
* Used to be possible to trigger code coverage builds with 'try: -b o -p linux64-cc -u all -t none', but I think this is broken now. Probably isn't terribly hard to revive this. Needs further investigation.

=== charts.mozilla.org ===

* '''Docs''' -
* '''Code''' - https://github.com/mozilla/charts
* '''Contact' - klahnakoski@mozilla.com
* '''Inputs''' -
** BMO/ES Cluster (https://esfrontline.bugzilla.mozilla.org:443/public_bugs/bug_version)
* '''Outputs/Services'''
** http://charts.mozilla.org (for management)

=== CodeCoverage ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/CodeCoverage
* '''Code'''
** '''UI''' - https://github.com/chinhodado/codecoverage_presenter
** '''ETL''' - https://github.com/klahnakoski/ActiveData-ETL/blob/dev/activedata_etl/transforms/jscov_to_es.py
* '''Contact''' - jmaher@mozilla.com, klahnakoski@mozilla.com, chmanchester@mozilla.com
* '''Inputs'''
** Various tests have been configured with a code coverage option
* '''Outputs/Services'''
** ActiveData - https://wiki.mozilla.org/Auto-tools/Projects/ActiveData
** http://chinhodado.github.io/codecoverage_presenter/

=== Datazilla (retired) ===

* '''Docs''' - https://datazilla.readthedocs.org/en/latest/
* '''Code''' - https://datazilla.readthedocs.org/en/latest/
* '''Contact''' - See Treeherder
* '''Inputs'''
** data pushed from Talos (see Graph Server)
* '''Outputs/Services'''
** charts at https://datazilla.mozilla.org
** raw results at https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob

=== DevelopmentMetrics ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/DevelopmentMetrics
* '''Code''' - https://github.com/klahnakoski/MoDevMetrics
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Bugzilla/ES Cluster
* '''Outputs/Services'''
** various charts and dashboards

=== DevTools Harness ===

* '''Docs''' - Needs project page!
* '''Contact''' - [:ted.mielczarek]

=== dzAlerts (retired)===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Alerts
* '''Code''' - https://github.com/klahnakoski/datazilla-alerts
* '''Contact''' - klahnakoski@mozilla.com
* '''Inputs'''
** Datazilla web service (https://datazilla.mozilla.org/talos/refdata/objectstore/json_blob)
** Eideticket web service (http://eideticker.mozilla.org)
* '''Outputs/Services'''
** fxos-perf-alerts@mozilla.org (b2g sheriffs?)

=== Eideticker ===

* '''Docs''' - https://wiki.mozilla.org/Project_Eideticker#Documentation
* '''Code''' - https://github.com/mozilla/eideticker
* '''Contact''' - William Lachance, Dave Hunt
* '''Inputs'''
** Nightly/inbound b2g and android builds.
* '''Outputs/Services'''
** Eideticker dashboard (http://eideticker.mozilla.org)

=== m21s ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/m21s
* '''Code''' - see project page
* '''Contacts''' - [:chmanchester][:ahal][:whimboo]
* '''Inputs'''
** Mozmill release tests
* '''Outputs'''
** 'Firefox Greenlight Tests' in Marionette, reporting to Treeherder

=== Marionette ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Marionette
* '''Code''' -
* '''Contact''' - [:AutomatedTester][:ato]
* '''What''' - Mozilla's native WebDriver implementation

=== Mozharness ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Mozharness
* '''Code''' - https://hg.mozilla.org/build/mozharness/
* '''Contact''' - [:armenzg]
* '''Inputs'''
** command-line invocation via buildbot or locally
* '''Outputs/Services'''
** build/test logs consumed by buildbot, Treeherder, TBPL

=== MozReview (Review Board) ===
* '''Docs''' - [[Auto-tools/Projects/CodeReviewTool]]
* '''Code''' - various pieces of https://hg.mozilla.org/hgcustom/version-control-tools; see docs for more.
* '''Contact''' - mcote@mozilla.com
* '''Inputs'''
** BMO
** hg.mozilla.org
* '''Outputs/Services'''
** BMO

=== OrangeFactor ===

* '''Docs''' - [[Auto-tools/Projects/OrangeFactor]]
* '''Code''' - https://hg.mozilla.org/automation/orangefactor/
* '''Contact''' - :jgriffin, :mcote
* '''Inputs'''
** buildbot messages (using pulse)
** build logs
** comments from TBPL
** bugzilla bug data
* '''Outputs/Services'''
** https://brasstacks.mozilla.com/orangefactor/
** email status [War on Orange]

=== Ouija ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Ouija
* '''Code''' - https://github.com/dminor/ouija.git
* '''Contact''' - dminor, jmaher
* '''Inputs'''
** https://hg.mozilla.org/
** tbpl.mozilla.org
* '''Outputs/Services'''
** http://54.215.155.53

=== Perfherder ===
* '''Docs''' - https://wiki.mozilla.org/EngineeringProductivity/Projects/Perfherder
* '''Code''' - https://github.com/mozilla/treeherder/tree/master/treeherder/perf
* '''Contact''' - :wlach
* '''Inputs'''
** PERFHERDER_DATA: see format http://wrla.ch/blog/2015/11/perfherder-onward/
* '''Outputs/Services'''
** https://treeherder.mozilla.org/perf.html#/graphs

=== Pulse ===
* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Pulse
* '''Code''' - https://hg.mozilla.org/automation/mozillapulse
* '''Contact''' - Mark Côté
* '''Inputs''' (exchanges? http://christian.legnitto.com/blog/2010/07/17/mozilla-pulse-and-rabbitmq/)
** a multitude of other systems
* '''Outputs/Services'''
** a multitude of other systems
** https://pulse.mozilla.org/

=== PulseTranslator ===
* '''Docs''' - https://github.com/mozilla/pulsetranslator/blob/master/README.md
* '''Code''' - https://github.com/mozilla/pulsetranslator
* '''Contact''' - jgriffin@mozilla.com
* '''Inputs'''
** Pulse exchange/build
* '''Outputs/Services'''
** Pulse exchange/build/normalized

=== Structured Logging ===
* '''Docs''' - https://mozbase.readthedocs.org/en/latest/loggingreporting.html, https://wiki.mozilla.org/Auto-tools/Projects/Structured_Logging
* '''Contacts''' - [:chmanchester][:ahal][:jgraham]

=== Talos ===
* '''Docs''' - https://wiki.mozilla.org/Buildbot/Talos
* '''Code''' - https://hg.mozilla.org/build/talos
* '''Contact''' - jmaher@mozilla.com
* '''Inputs'''
** build for desktop or android
** commandline (done via mozharness now) to specify which test(s) to run
* '''Outputs/Services'''
** log file with raw data
** uploaded summarization of data to graph server
** uploaded raw data to datazilla

Can be referred to as what is run by buildbot or by tbpl since this is the only performance test run on our per revision CI system. Other tools are run at a different cadence.

=== TBPL (for the sake of history) ===

* '''Docs''' - [[Sheriffing/TBPL]]
* '''Code''' - https://hg.mozilla.org/webtools/tbpl/
* '''Contact''' - [[Sheriffing/TBPL#Developer_Contacts]]
* '''Inputs'''
**
* '''Outputs/Services'''
**

=== Test Informant ===

* '''Docs''' - https://wiki.mozilla.org/Auto-tools/Projects/Test-Informant
* '''Code''' - See project page
* '''Contact''' - [:ahal]
* '''Inputs'''
** build notifications via pulse
** test manifests in tests.zip
* '''Outputs'''
** reports at e.g., http://brasstacks.mozilla.com/testreports/weekly

=== Treeherder ===
* '''Docs''' - [[Auto-tools/Projects/Treeherder]]
* '''Code''' - [[Auto-tools/Projects/Treeherder#Source_and_Docs]]
* '''Contact''' - [:camd][:mdoglio][:edmorley]
* '''Inputs'''
** Pushlog from hg.mozilla.org via json-pushes
** Build/tests from Buildbot via buildapi
** Direct pushes via ``treeherder-client``
** Build/tests from Taskcluster (under development)
* '''Outputs/Services'''
** https://treeherder.mozilla.org/
** https://treeherder.mozilla.org/api/

=== web-platform-tests ===
* '''Docs''' - https://wptrunner.readthedocs.org/en/latest/, Needs project page?
* '''Code'''
** https://github.com/w3c/web-platform-tests/
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/README.md
** https://github.com/mozilla/gecko-dev/blob/master/testing/web-platform/tests/README.md
* '''Contact''' - [:jgraham]

== Example ==

Use the EMPTY TEMPLATE to add more entries. Include ones you know about, even if you can not fill them.

=== EXAMPLE ===
* '''Docs''' - some wiki, or read the docs to learn more
* '''Code''' - link to code, if it makes sense
* '''Contact''' - for ekyle to contact if he has questions
* '''Inputs''' -
** automated resources
** services consumed
* '''Outputs/Services'''
** automated services provided
** dashboards (and teams that consume them)

=== EMPTY TEMPLATE ===
* '''Docs''' -
* '''Code''' -
* '''Contact''' -
* '''Inputs'''
**
* '''Outputs/Services'''
**