Wednesday November 26, 2014 16:20, Will Kahn-Greene | Tweet this

Since the beginning of 2014, I've been laying the groundwork to rewrite the feedback form that we use on Input.

Today, after a lot of work, we pushed out the new form! Just in time for Firefox 34 release.

This blog post covers the circumstances of the rewrite.

Why?

In 2011, James, Mike and I rewrote Input from the ground up. In order to reduce the amount of time it took to do that rewrite, we copied a lot of the existing forms and styles including the feedback forms. At that time, there were two: one for desktop and one for mobile. In order to avoid a translation round, we kept all the original strings of the two forms. The word "Firefox" was hardcoded in the strings, but that was fine since at the time Input only collected feedback for Firefox.

In 2013, in order to reduce complexity on the site because there's only one developer (me), I merged the desktop and mobile forms into one form. In order to avoid a translation round, I continued to keep the original strings. The wording became awkward and the flow through the form wasn't very smooth. Further, the form wasn't responsive at all, so it worked ok on desktop machines, but mediocre on other viewport sizes.

2014 rolled around and it was clear Input was going to need to branch out into capturing feedback for multiple products---some of which were not Firefox. The form made this difficult.

Related, the smoketest framework I wrote in 2014 struggled with testing the form accurately. I spent some time tweaking it, but a simpler form would make smoketesting a lot easier and less flakey.

Thus over the course of 3 years, we had accumulated the following problems:

The flow through the form felt awkward, instructions weren't clear and information about what data would be public and what data would be private wasn't clear.
Strings had "Firefox" hardcoded and wouldn't support multiple products.
The form wasn't responsive and looked/behaved poorly in a variety of situations.
The form never worked in right-to-left languages and possibly had other accessibility issues.
The architecture didn't let us experiment with the form---tweaking the wording, switching to a more granular gradient of sentiment, capturing other data, etc.

Further, we were seeing many instances of people putting contact information in the description field and there was a significant amount of dropoff.

I had accrued the following theories:

Since the email address is on the third card, users would put their email address in the description field because they didn't know they could leave their contact information later.
Having two cards would reduce the amount of drop-off and unfinished forms than three cards.
Having simpler instruction text would reduce the amount of drop-off.

Anyhow, it was due for an overhaul.

So what's changed?

I've been working on the overhaul for most of 2014, but did the bulk of the work in October and November. It has the following changes:

The new form is shorter and clearer text-wise and design-wise.
It consists of two cards: one for capturing sentiment and one for capturing details about that sentiment.
It clearly delineates data that will be public from data that will be kept private.
It works with LTR and RTL languages (If that's not true, please open a bug.)
It fixes some accessibility issues. (If you find any, please open a bug.)
It uses responsive design, mobile first. Thus it was designed for mobile devices and then scaled to desktop-sized viewports.
It's smaller in kb size and requires fewer HTTP requests.
It's got a better architecture for future development.
It doesn't have "Firefox" hardcoded anymore.
It's simpler so the smoketests work reliably now.

The old Input feedback form.

The new Input feedback form.

Note: Showing before and after isn't particularly exciting since this is only the first card of the form in both cases.

Going forward

The old and new forms were instrumented in various ways, so we'll be able to analyze differences between the two. Particularly, we'll be able to see if the new form performs worse.

Further, I'll be checking the data to see if my theories hold true especially the one regarding why people put contact data in the description.

There are a few changes in the queue that we want to make over the course of the next 6 months. Now that the new form has landed, we can start working on those.

Even if there are problems with the new form, we're in a much better position to fix them than we were before. Progress has been made!

Take a moment---try out the form and tell us YOUR feedback

Have you ever submitted feedback? Have you ever told Mozilla what you like and don't like about Firefox?

Take a moment and fill out the feedback form and tell us how you feel about Firefox.

Thanks, etc

I've been doing web development since 1997 or so. I did a lot of frontend work back then, but I haven't done anything serious frontend-wise in the last 5 years. Thus this was a big project for me.

I had a lot of help: Ricky, Mike and Rehan from the SUMO Engineering team were invaluable reviewing code, helping me fix issues and giving me a huge corpus of examples to learn from; Matt, Gregg, Tyler, Ilana, Robert and Cheng from the User Advocacy team who spent a lot of time smoothing out the rough edges of the new form so it captures the data we need; Schalk who wrote the product picker which I later tweaked; Matej who spent time proof-reading the strings to make sure they were consistent and felt good; the QA team which wrote the code that I copied and absorbed into the current Input smoketests; and the people who translated the user interface strings (and found a bunch of issues) making it possible for people to see this form in their language.

Input: Removing the frontpage chart

Tuesday October 28, 2014 10:00, Will Kahn-Greene | Tweet this

I've been working on Input for a while now. One of the things I've actively disliked was the chart on the front page. This blog post talks about why I loathe it and then what's happening this week.

First, here's the front page dashboard as it is today:

Input front page dashboard (October 2014)

When I started, Input gathered feedback solely on the Firefox desktop web browser. It was a one-product feedback gathering site. Because it was gathering feedback for a single product, the front page dashboard was entirely about that single product. All the feedback talked about that product. The happy/sad chart was about that product. Today, Input gathers feedback for a variety of products.

When I started, it was nice to have a general happy/sad chart on the front page because no one really looked at it and the people who did look at it understood why the chart slants so negatively. So the people who did look at it understood the heavy negative bias and could view the chart as such. Today, Input is viewed by a variety of people who have no idea how feedback on Input works or why it's so negatively biased.

When I started, Input didn't expose the data in helpful ways allowing people to build their own charts and dashboards to answer their specific questions. Thus there was a need for a dashboard to expose information from the data Input was gathering. I contend that the front page dashboard did this exceedingly poorly--what does the happy/sad lines actually mean? If it dips, what does that mean? If they spike, what does that mean? There's not enough information in the chart to make any helpful conclusions. Today, Input has an API allowing anyone to fetch data from Input in JSON format and generate their own dashboards of which there are several out there.

When I started, Input received some spam/abuse feedback, but the noise was far outweighed by the signal. Today, we get a ton of spam/abuse feedback. We still have no good way of categorizing spam/abuse as such and removing it from the system. That's something I want to work on more, but haven't had time to address. In the meantime, the front page dashboard chart has a lot of spammy noise in it. Thus the happy/sad lines aren't accurate.

Thus I argue we've far outlived the usefulness of the chart on the front page and it's time for it to go away.

So, what happens now? Bug 1080816 covers removing the front page dashboard chart. It covers some other changes to the front page, but I think I'm going to push those off until later since they're all pretty "up in the air".

If you depend on the front page dashboard chart, toss me an email. Depending on how many people depend on the front page chart and what the precise needs are, maybe we'll look into writing a better one.

Input: 2014q3 post-mortem

Tuesday October 07, 2014 18:00, Will Kahn-Greene | Tweet this

This is the 2014q3 Input post-mortem. It was a better quarter than 2014q2--that one kind of sucked. Instead 2014q2 started out well and then got kind of busy and then I was pretty overwhelmed by the end.

Things to know:

Input is Mozilla's product feedback site.
Fjord is the code that runs Input.
I unilaterally decided to extend 2014q3 to October 6th.
I am Will Kahn-Greene and I'm the primary developer on Input.

Bug and git stats

Bugzilla
========

Bugs created:        58
Bugs fixed:          54

git
===

Total commits: 161

      Will Kahn-Greene :   150  (+195704, -188071, files 672)
         Ian Kronquist :     7  (+201, -53, files 11)
         L. Guruprasad :     3  (+8, -18, files 3)
       Ruben Vereecken :     1  (+34, -14, files 6)

Total lines added: 195947
Total lines deleted: 188156
Total files changed: 692

We added a bunch of code this quarter:

October 7th. 2014: 23466 total, 11614 Python

Compare to previous quarters:

2014q1: April 1st, 2014: 15195 total, 6953 Python
2014q2: July 1st, 2014: 20456 total, 9247 Python

Nothing wildly interesting there other than noting that the codebase for Input continues to grow.

Contributor stats

Ian Kronquist was the Input intern for Summer 2014. He contributed several fixes to Input. Yay!

We spent a bunch of time making our docs and Vagrant provisioning script less buggy so as to reduce the problems new contributors have when working on Input. I talked with several people about things they're interested in working on. Plus several people did some really great work on Input.

Generally, I think Input is at a point where it's not too hard to get up and running, we've got several lists of bugs that are good ones to start with and the documentation is good-ish. I think the thing that's hampering us right now is that I'm not spending enough time and energy answering questions, managing the work and keeping things going.

Anyhow, welcome L. Guruprasad, Adam Okoye and Ruben Vereecken! Additionally, many special thanks to L. Guruprasad who fixed a lot of issues with the Vagrant provisioning scripts. That work is long and tedious, but it helps everyone.

Accomplishments

Dashboards for everyone: We wrote an API and some compelling examples of dashboards you can build using the API. It's being used in a few places now. We'll grow it going forward as needs arise. I'm pretty psyched about this since it makes it possible for people with needs to help themselves and not have to wait for me to get around to their work. Dashboards for everyone project plan.

Vagrant: We took the work I did last quarter and improved upon it, rewrote the docs and have a decent Vagrant setup now. Reduce contributor pain project plan.

Abuse detection: Ian spent his internship working on an abuse classifier so that we can more proactively detect and prevent abusive feedback from littering Input. We gathered some interesting data and the next step is probably to change the approach we used and apply some more complex ML things to the problem. The key here is that we want to detect abuse with confidence and not accidentally catch swaths of non-abuse. Input feedback has some peculiar properties that make this difficult. Reduce the abuse project plan.

Loop support: Loop is now using Input for user sentiment feedback.

Heartbeat support: User Advocacy is working on a project to give us a better baseline for user sentiment. This project was titled Heartbeat, but I'm not sure whether that'll change or not. Regardless, we added support for the initial prototype. Heartbeat project plan.

Data retention policy: We've been talking about a data retention policy for some time. We decided on one, finalized it and codified it in code.

Shed the last vestiges of Playdoh and funfactory: We shed the last bits of Playdoh and funfactory. Input uses the same protections and security decisions those two projects enforced, but without being tied to some of the infrastructure decisions. This made it easier to switch to peep-based requirements management.

Switched to FactoryBoy and overhauled tests: Tests run pretty fast in Fjord now. We switched to FactoryBoy, so writing model-based tests is a lot easier than the stuff we had before.

Summary

Better than 2014q2 and we fixed some more technical debt further making it easier to develop for and maintain Input. Still, there's lots of work to do.

Update April 21st, 2015

LGuruprasad found a bug in the script that caused commits-by-author information to be wrong. Fixed the script and updated the stats!

Input: Dashboards for Everyone v1

Monday October 06, 2014 12:00, Will Kahn-Greene | Tweet this

Summary

In 2014q3, I created the Dashboards for Everyone project. This blog post covers what the project is, what's out there now, some examples of usage and the future.

Input collects sentiment data on Mozilla products. Currently, this data can be seen on the front page dashboard. This dashboard sucks for a variety of reasons amongst which is that it's a slog of data that isn't particularly informative.

Further, it's pretty clear that the greater Mozillaverse has different informational needs. Some people are interested in issues with products in specific locales. Some people are interested in today's hot topic. Some people are interested in comparing the first week after release of one version of a product with another. Etc.

Given that, we have two paths:

Create dashboards that live on Input catering to all these needs.
Create an API that allows people to create their own dashboards and host them wherever.

These two paths aren't mutually exclusive. However, I want to put effort into the second one first for the following reasons:

It enables people to individually and collectively solve their own informational problems.
It enables people to solve informational problems as problems crop up rather than wait for Input developers to have time to write up a dashboard.
As people are solving their informational problems, we'll learn a lot more about what informational problems exist which will guide how we build dashboards that live on Input.

The Dashboards for Everyone project aims to create the infrastructure for enabling people to write their own dashboards using Input data.

Version 1

Over the course of the quarter we put enough of the bits in place that building your own dashboard is a viable thing now.

First, we wrote and honed an API for getting feedback data.

Then we wrote a bunch of proof-of-concept dashboards that use this data.

I threw together these two dashboards which are defined in Github gists and "hosted" on bl.ocks.org:

Happy feedback: http://bl.ocks.org/willkg/c4d5a272f86ae4510750
Happy vs. Sad broken down by locale for Firefox OS: http://bl.ocks.org/willkg/e6013b21ec16d5e8192a

Ian Kronquist (Input intern for summer 2014) wrote this one:

Happitude comparison: http://bl.ocks.org/iankronquist/90f68ed445f804e63cdb

Those are examples of fetching and manipulating the data into a chart. They're not very informative. We used them to help flesh out the API and their current purpose is as examples for using the API to do things.

However, we've built some real things that use the data and are "in production" now:

I use the Input API for the Response Breakdown graphs on the Input Health Dashboard. That helps me figure out whether we've just pushed out bugs preventing people from leaving feedback. That uses a d3-based charting library I've been toying with to help me flesh out possible data transform needs. It also uses a library that lets me defined the charts in HTML attributes and they get "auto-charted" without me having to write JavaScript.
Cheng used the Input API to build the Hello dashboard for tracking Hello feedback.
I then reused most of his ideas and some of his code to produce a Firefox for Android trends dashboard. That's still got some issues namely that the tokenizing isn't very good and thus there's enough noise in the words lists that it doesn't bring real trending issues into starker relief.

That's where we're at. Now I need to tell people about it so that you know these possibilities exist.

Do you have informational needs for the data on Input?

Can the API help you solve your specific needs?

Are there important things missing that you need to have implemented in order to solve your needs?

If you use the Input API to build your own dashboards and you run into problems, write up a bug.

Version 2 and future

Bugs, conversations and seeing other peoples' dashboards will inform us as to how we need to grow the API going forward. That will set the priorities for the next version.

Also, I have a few ideas I've been mulling over:

Build an index of charts: If there are a sufficient number of interesting charts out there, then we should build an index of them on Input.
Build tokenizing into the Input API: If you look at the JavaScript code for my Firefox for Android Trends chart, a good portion of it deals with tokenizing. If tokenizing is a common thing people are doing to build charts, then we should pull that tokenizing in-house.
Build an auto-charter or chart widget library: Right now you have to do all the charting by hand. It'd be really nice to be able to throw dashboards together using chart "widgets" and possibly define the dashboard entirely in HTML. I've been toying with this with the Input Health Dashboard. I'm curious to find out if there's a need for throwing dashboards together quickly to follow certain issues (e.g. e10s, Hello, ...).

The Metrics team produces some really great looking dashboards that use MetricsGraphics.js. Maybe we could build a shim on top of that letting people more easily use that library with Input data?

Thanks

I really want to thank Matt Grimes for coordinating d3 training, Cheng Wang for giving me some compelling code to reuse and Mike Cooper for helping me debug code whose mystery was only exceeded by its brokenness.

Thoughts, comments, etc

I'm using the fruits of this labor now, so at a bare minimum, it solved some of my problems.

Can it help you solve yours?

Input status: September 12th, 2014

Friday September 12, 2014 16:20, Will Kahn-Greene | Tweet this

Development

High-level summary:

Updated to ElasticUtils v0.10 which will allow us to upgrade our cluster to Elasticsearch 1.1. I'm working on a fix that'll let us to go to Elasticsearch 1.2, but that hasn't been released, yet.
Integrated the spicedham library prototype and set it up to classify abusive Input feedback. It's not working great, but that's entirely to be expected. I'm hoping to spend more time on spicedham and classification in Input in 2014q4. Ian did a great job with laying the foundation! Thank you, Ian!
Implemented a data retention policy and automated data purging.
Made some changes to the Input feedback GET and POST APIs to clarify things in the docs, fix some edge cases and make it work better for Firefox for Android and Loop.
Fixed the date picker in Chrome. Thank you, Ruben!

Landed and deployed:

c4e8e34 [[bug 1055520]] Update to ElasticUtils v0.10
e023fa4 [[bug 1055520]] Fix two reshape issues post EU 0.10 update
f9ba829 [[bug 1055785]] Codify data retention policy
91396a8 Generalize About page text so it works for all products
6fc03bf [[bug 1053863]] Update django to 1.5.9
85709b2 [[bug 1055788]] Implement data purging
c0677a1 [[bug 965796]] Add a products update page
121588d [[bug 1057353]] Update django-statsd and pystatsd
fe1c740 Add PII-related notes to the API fields
f77ecfa [[bug 799562]] Clarify API field documentation
c5eec03 [[bug 1055789]] Restrict front page dashboard and api to 6 months
0892546 [[bug 1059826]] Add max_length to url field in API
f192f84 [[bug 1057617]] Fix url data validation
aad961d [[bug 1030901]] Document Input GET API
2f212c5 [[bug 1015788]] Add flake8 linting
d673947 Update coding conventions
27a1b6b Add "maximum" arg to GET API
4f671e4 [[bug 1062436]] Add flags app and Flag model
9d03d4b Fix flake8_lint issues
0411d91 [[bug 1062453]] Add flagged view
56f7e24 [[bug 1062439]] Celery task for classification
7aa2930 [[bug 1062455]] Add spicedham to vendor (Ian Kronquist)
0d90df3 We don't need spicedham under vendor/packages (Ian Kronquist)
a2a491d fix [bug 1012965] - Date picker looks broken in chrome (Ruben Vereecken)
0c42213 [[bug 1063825]] Integrate spicedham into fjord
78a2d63 [[bug 1062444]] Initial training data
5ca816e [[bug 1020307]] Prepare for adding gradient to generic form

Current head: 5ca816e

Rough plan for the next two weeks

Working on Dashboards-for-everyone bits. Documenting the GET API. Making it a bit more functional. Writing up some more examples. (https://wiki.mozilla.org/Firefox/Input/Dashboards_for_Everyone)
Gradients (https://wiki.mozilla.org/Firefox/Input/Gradient_Sentiment)

What I need help with

(django) Update to django-rest-framework 2.3.14 (bug #934979) -- I think this is straight-forward. We'll know if it isn't if the tests fail.
(django, cookies, debugging) API response shouldn't create anoncsrf cookie (bug #910691) -- I have no idea what's going on here because I haven't looked into it much.

For details, see our GetInolved page:

https://wiki.mozilla.org/Webdev/GetInvolved/input.mozilla.org

If you're interested in helping, let me know! We hang out on #input on irc.mozilla.org and there's the input-dev mailing list.

Additional thoughts

I've been codifying project plan details on the wiki:

https://wiki.mozilla.org/Firefox/Input

I have no idea who's going to use that information or whether it helps. If you see things that are missing, let me know. It'll help me hone the project management templates I'm using and know which information is important to keep up to date and which information I can let slide until rainy days.

That's it!

Input status: August 19th, 2014

Tuesday August 19, 2014 14:11, Will Kahn-Greene | Tweet this

Development

High-level summary:

It's been a slower two weeks than normal, but we still accomplished some interesting things:

L Guruprasad finished cleaning up the Getting Started guide--that work helps all future contributors. He did a really great job with it. Thank you!
Landed a minor rewrite to rate-limiting/throttling.
Redid the Elasticsearch indexing admin page.
Fixed some Heartbeat-related things.

Landed and deployed:

cf2e0e2 [[bug 948954]] Redo index admin
f917d41 Update Getting Started guide to remove submodule init (L. Guruprasad)
5eb6d6d Merge pull request #329 from lgp171188/peepify_submodule_not_required_docs
c168a5b Update peep from v1.2 to v1.3
adf7361 [[bug 1045623]] Overhaul rate limiting and update limits
7647053 Fix response view
f867a2d Fix rulename
8f0c36e [[bug 1051214]] Clean up DRF rate limiting code
0f0b738 [[bug 987209]] Add django-waffle (v0.10)
b52362a Make peep script executable
461c503 Improvie Heartbeat API docs
8f0ccd3 [[bug 1052460]] Add heartbeat view
d1604f0 [[bug 1052460]] Add missing template

Landed, but not deployed:

ed2923f [[bug 1015788]] Cosmetic: flake8 fixes (analytics)
afdfc6a [[bug 1015788]] Cosmetic: flake8 fixes (base)
05e0a33 [[bug 1015788]] Cosmetic: flake8 fixes (feedback)
2d9bc26 [[bug 1015788]] Cosmetic: flake8 fixes (heartbeat)
dc6e990 Add anonymize script

Current head: dc6e990

Rough plan for the next two weeks

Working on Dashboards-for-everyone bits. Documenting the GET API. Making it a bit more functional. Writing up some more examples. (https://wiki.mozilla.org/Firefox/Input/Dashboards_for_Everyone)
Update Input to ElasticUtils v0.10 ([bug 1055520])
Land all the data retention policy work ([bug 946456])
Gradients (https://wiki.mozilla.org/Firefox/Input/Gradient_Sentiment)
Product administration views ([bug 965796])

Most of that is in some state of half-done, so we're going to spend the next couple of weeks focusing on finishing things.

What I need help with

(django) Update to django-rest-framework 2.3.14 ([bug 934979]) -- I think this is straight-forward. We'll know if it isn't if the tests fail.
(django, cookies, debugging) API response shouldn't create anoncsrf cookie ([bug 910691]) -- I have no idea what's going on here because I haven't looked into it much.
(html) Fixing the date picker in Chrome ([bug 1012965]) -- The issue is identified. Someone just needs to do the fixing.

For details, see our GetInolved page:

https://wiki.mozilla.org/Webdev/GetInvolved/input.mozilla.org

If you're interested in helping, let me know! We hang out on #input on irc.mozilla.org and there's the input-dev mailing list.

Additional thoughts

We're in the process of doing a Personally Identifiable Information audit on Input, the systems it's running on and the processes that touch and move data around. This covers things like "what data are we storing?", "where is the data stored?", "who/what has access to that data?", "does that data get copied/moved anywhere?", "who/what has access to where the data gets copied/moved to?", etc.

I think we're doing pretty well. However, during the course of the audit, we identified a few things we should be doing better. Some of them already have bugs, one of them is being worked on already and the otehrs need to be written up.

Some time this week, I'll turn that into a project and write up missing bugs.

That's about it!

Input status: August 4th, 2014

Monday August 04, 2014 11:28, Will Kahn-Greene | Tweet this

Summary

This is the status report for development on Input. I publish a status report to the input-dev mailing list every couple of weeks or so covering what was accomplished and by whom and also what I'm focusing on over the next couple of weeks. I sometimes ruminate on some of my concerns. I think one time I told a joke.

Work summary

Continued work on the development environment with awesome help from L. Guruprasad
Implement the bits required to support Loop
Add smoketest coverage for Firefox OS feedback form
Fix some technical debt issues

Development

Landed and deployed:

6097571 [[bug 1040919]] Change version to only have one dot
dcf8f91 [[bug 1040919]] Fix .0.0 versions to .0
4012933 Remove CEF-related things
4887c49 [[bug 1030905]] Add product/version tests
1bdd3a8 [[bug 1042222]] update Vagrantfile to use 14.04 LTS (L. Guruprasad)
c1bdfbb Add L. Guruprasad to CONTRIBUTORS
3e607a5 [[bug 1042560]] Remove unused packages in dev VM (L. Guruprasad)
c0759d1 Update django-mozilla-product-details
bcf8ec8 Update product details
58579ab [[bug 987801]] peep-ify requirements
248b0ab [[bug 987801]] Exit if requirements are mismatched
5db57bc [[bug 987801]] Redo how we figure out whether to use vendor/
df8400d Fix sampledata generation to use bulk create
fa0caac [[bug 1041622]] Capture querystring slop
98745b5 [[bug 1021155]] Add basic FirefoxOS smoketest
6cf9e39 [[bug 1041664]] Capture slop in Input API
ff4b711 Show context in response view
976ebbf [[bug 1045942]] Add category to response table
34622ad Add docs for category and extra context for Input API
d1a8dd5 Add an additional note about keys
fec1319 [[bug 998726]] Quell Django warnings
288afe4 Rename fjord/manage.py to fjord/manage_utils.py
d40e8a9 Update dennis to v0.4.3

Landed, but not deployed:

28cd90f [[bug 1047681]] Fix mlt call to be more resilient

Current head: 28cd90f

Over the next two weeks

Keep an eye out for any Loop or Heartbeat related work--that's top priority.
Work on gradient support and product picker support

What I need help with

(Google chrome, JavaScript, CSS, HTML) Investigate what's wrong with the date picker in Chrome and fix it [[bug 1012965]]
Test out the Getting Started instructions. We've had a few people go through these already, but it's definitely worth having more eyes. http://fjord.readthedocs.org/en/latest/getting_started.html

If you're interested in helping, let me know! We hang out on #input on irc.mozilla.org and there's the input-dev mailing list.

That's it!

Input status: July 20th, 2014

Sunday July 20, 2014 11:37, Will Kahn-Greene | Tweet this

Summary

Last status report was at the end of June. This status report covers the last few things we landed in 2014q2 as well as everything we've done so far in 2014q3.

Development

Landed and deployed:

6ecd0ce [[bug 1027108]] Change default doc theme to mozilla sphinx (Anna Philips)
070f992 [[bug 1030526]] Add cors; add api feedback get view
f6f5bc9 [[bug 1030526]] Explicitly declare publicly-visible fields
c243b5d [[bug 1027280]] Add GengoHumanTranslater.translate; cleanup
3c9cdd1 [[bug 1027280]] Add human tests; overhaul Gengo tests
ff39543 [[bug 1027280]] Add support for the Gengo sandbox
258c0b5 [[bug 1027280]] Add test for get_balance
44dd8e5 [[bug 1027280]] Implement Gengo Human push_translations
35ae6ec [[bug 1027280]] Clean up API code
a7bf90a [[bug 1027280]] Finish pull_translations and tests
c9db147 [[bug 1027286]] Gengo translation system status
f975f3f [[bug 1027291]] Implement spot Gengo human translation
f864b6b [[bug 1027295]] Add translation_sync cron job
c58fd44 [[bug 1032226]] en-GB should copyover, too
7480f87 [[bug 1032226]] Tweak the code to be more defensive
7ac1114 [[bug 1032571]] CSRF exempt the API
ac856eb [[bug 1032571]] Fix tests to catch csrf issues in the api
74e8e09 [[bug 1032967]] Handle unsupported language pairs
74a409e [[bug 1026503]] First pass at vagrantification
a7a440f Continued working on docs; ditched hacking howto
44e702b [[bug 1018727]] Backfill translations
69f9b5b Fix date_end issue
e59d4f6 [[bug 1033852]] Better handle unsupported src languages
cc3c4d7 Add list of unsupported languages to admin
32e7434 [[bug 1014874]] Fix translate ux
672abba [[bug 1038774]] Hide responses from hidden products
e23eca5 Fix a goof in the last commit
6f78e2e [[bug 947767]] Nix authentication for API stuff
a9f2179 Fix response view re: non-existent products
e4c7c6c [Bug 1030905] fjord feedback api tests for dates (Ian Kronquist)
0d8e024 [[bug 935731]] Add FactoryBoy
646156f Minor fixes to the existing API docs
f69b58b [[bug 1033419]] Heartbeat backend prototype
f557433 [[bug 1033419]] Add docs for heartbeat posting

Landed, but not deployed:

7c7009b [[bug 935731]] Switch all tests to use FactoryBoy
2351fb5 Generate locales so ubuntu will quite whining (Ian Kronquist)

Current head: 7ea9fc3

High-level

At a high level, this is:

Landed automated Gengo human translation and a bunch of minor fixes to make it work more smoothly.
Reworked how we build development environments to use vagrant. This radically simplifies the instructions and should make it a lot easier for contributors to build a development environment. This in turn should lead to more people working on Input.
Fixed a bug where products marked as "hidden" were still showing up in the dashboard.
Implemented a GET API for Input responses. (https://wiki.mozilla.org/Firefox/Input/Dashboards_for_Everyone)
Implemented the backend for the Heartbeat prototype. (https://wiki.mozilla.org/Firefox/Input/Heartbeat)
Also, I'm fleshing out the Input section in the wiki complete with project plans. (https://wiki.mozilla.org/Firefox/Input)

Over the next two weeks

Continue fleshing out project plans for in-progress projects on the wiki.
Gradient sentiment and product picker work.

What I need help with

We have a new system for setting up development environments. I've tested it on Linux. Ian has, too (pretty sure he's using Linux). We could use some help testing it on Windows and Mac OSX.

Do the instructions work on Windows? Do the instructions work on Mac OSX? Are there important things the instructions don't cover? Is there anything confusing?

http://fjord.readthedocs.org/en/latest/getting_started.html

I'm changing the way I'm managing Fjord development. All project plans will be codified in the wiki. A rough roadmap of which projects are on the drawing board, in-progress, completed, etc is also on the wiki. I threw together a structure for all of this that I think is good, but it could use some review.

Do these project plans provide useful information? Are there important questions that need answering that the plans do not answer?

https://wiki.mozilla.org/Firefox/Input

If you're interested in helping, let me know! We hang out on #input on irc.mozilla.org and there's the input-dev mailing list.

I think that covers it!

Input: 2014q2 post-mortem

Tuesday July 01, 2014 14:20, Will Kahn-Greene | Tweet this

I'm going to start doing quarterly post-mortems for Input development. The goal is to be more communicative about what happened, why, what's in the works and what I need more help with.

NB: "Fjord" is the name of the codebase that runs Input.

Bug and git stats

Bugzilla
========

Bugs created:        63
Bugs fixed:          54

git
===

Total commits: 151

      Will Kahn-Greene :   143  (+15123, -4602, files 446)
        ossreleasefeed :     3  (+197, -42, files 9)
          Joshua Smith :     2  (+65, -31, files 5)
          Anna Philips :     1  (+367, -3, files 12)
     Swarnava Sengupta :     1  (+2, -2, files 1)
         Ricky Rosario :     1  (+0, -0, files 0)

Total lines added: 15754
Total lines deleted: 4680
Total files changed: 473

We added a lot of lines of code this quarter:

April 1st, 2014: 15195 total, 6953 Python
July 1st, 2014: 20456 total, 9247 Python

That's a pretty big jump in LOC. I think a bunch of that is the translation-related changes.

Contributor stats

5 non-core people contributed to Fjord development.

I spent some time over the weekend finishing up Vagrant provisioning script and rewriting the docs. I'm planning to spend some more time in 2014q3 reducing the complexity and barriers for setting up a Fjord development environment to the point where someone can contribute.

Additionally, I'm planning to create more bugs that are contributor-friendly. I started doing that in the last week. I think a good goal for Input is to have around 20 contributor-y bugs hanging around at any given time.

Accomplishments

Site health dashboard: I wrote a mediocre site health dashboard that's good enough to give me a feel for how the site is performing before and after a deployment. This still needs some work, but I'll schedule that for a rainy day.

Client side smoke tests: I wrote smoke tests for the client side. I based it on the defunct input-tests code that QA was maintaining up until we rewrote Input. There are still a bunch of tests that I want to write to have a better coverage of things, but having something is way better than nothing. I'm hoping the smoke tests will reduce the amount of manual testing I'm doing, too.

Vagrant: I took some inspiration from Erik Rose and DXR and wrote a Vagrant provisioning shell script. This includes a docs overhaul as well. This work is almost done, but needs some more testing and will probably land in the next week or two. This will make peoples' lives easier.

Automated translation system (human and machine): I wrote an automated translation system. It's generalized so that it isn't model/field specific. It's also generalized so that we can add plugins for other translation systems. It's currently got plugins for Dennis, Gengo machine translation and Gengo human translation. I turned the automated human translation on yesterday and it seems to be working well. That was a HUGE project. I'm glad it's done.

One thing it includes is a lot of auditing and metrics gathering. This will make it possible for me to go back in time and look at how the translation system worked on various Input feedback responses and hone the system going forward to reduce the number of human translations we're doing and also reduce the number of problems we have doing them.

Better query syntax: We were upgraded to Elasticsearch 0.90.10. I switched the query syntax for the dashboard search field to use Elasticsearch simple_query_string. That allows users to express search queries they weren't previously able to express.

utm_source and utm_campaign handling: I finished the support for handling utm_source and utm_campaign querystring parameters. This allows us to differentiate between organic feedback and non-organic feedback.

More like this: I added a "more like this" section to the response view. This makes it possible for UA analyzers to look at a response and see other responses that are similar.

Dashboards for you, dashboards for everyone!

I'm putting this in its own section because it's intriguing. I'll write another blog post about it later in July as things gel.

On Thursday, a couple of days after d3 training that Matt organizied, I threw together a better GET API for Input feedback responses. It's not documented, it probably has some bugs and it's probably going to change a bit, but the gist of it is that it lets you more easily build a dashboard that meets your needs against live Input data.

Here's a proof-of-concept:

http://bl.ocks.org/willkg/c4d5a272f86ae4510750

That's looking at live Input data using the new GET API. The code is in a GitHub gist. It auto-updates every 2 minutes.

The problem is that I've got a ton of Input work to do and I just can't write dashboard code on Input fast enough. Further, of the people I've talked to that use the front page dashboard, they all have really different questions they're asking of the data. I'm hoping this alleviates that bottleneck by letting you and everyone else write dashboards that meet your needs.

I encourage you to take my proof-of-concept, fork the gist, tweak it, use bl.ocks.org or something to "host" the gist. Build the dashboard that answers your questions. Share it with other people. Plus, let me know about it. If you have issues with the API, submit a bug and tell me.

If this scratches the itch I think needs scratching, it should result in a bunch of interesting dashboards. If that happens, I'll write some code in Input to create a curated list of them so people can find them more easily.

Summary

This was a really crazy quarter and parts of it really sucked, but we got a lot accomplished and we laid some groundwork for some really interesting things for 2014q3.

Update April 21st, 2015

LGuruprasad found a bug in the script that caused commits-by-author information to be wrong. Fixed the script and updated the stats!

Input status: June 23rd, 2014

Monday June 23, 2014 10:25, Will Kahn-Greene | Tweet this

I publish a status report to the input-dev mailing list every couple of weeks or so covering what was accomplished and by whom and also what I'm focusing on over the next couple of week. I sometimes ruminate on some of my concerns. I think one time I told a joke.

Since the last report:

Landed and deployed:

fb83dd5 [[bug 1017828]] Add translation auditing
dccfb76 [[bug 1026019]] Rework bigram generation

Landed, but not deployed:

c348989 Add bug triaging for new contributors section
5b7dc67 Add Gengo API tests and skip_if infrastructure
98d30fb [[bug 1026131]] Add Gengo human translations bookkeeping
38d8584 [[bug 1026131]] Rework translations system logging code
1d9e67a [[bug 1027293]] Add audit records to response view

HEAD: 1d9e67a

Mostly I spent the last couple of weeks working on automated Gengo human translation support. This involved some infrastructure rewriting plus some additional infrastructure so that when we push all this out, we can see what's going on as it is happening.

Additionally, I went through and updated the mentor metadata for mentored bugs, added a bunch of new mentored bugs and worked with two potential contributors on them.

Over the next week (last week in 2014q2):

finish up automated Gengo human translation work

First thing in 2014q3, I'll spend some time "opening up" the development side of the project. This will make it easier/possible to follow and participate in development. I'm still figuring out some of the details and it's likely I'll continue to change how things work over the course of the quarter, but plan to follow advice from the Community Building team and Erik Rose who seems to be doing really super with DXR.