MozillaWiki - User contributions [en]

Community:SummerOfCode19:Brainstorming

2019-01-23T19:05:44Z

Dwalsh: Adding the debugger's new 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. If there is no category below for your corner of Mozilla, add one!

Here is the template for adding project proposals. Feel free to add new proposal to existing general categories, or add new categories as appropriate.

== 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
|-
| Support AdBlock Plus-style ad blocklists
| As of today, Gecko and GeckoView support ad blocking using a custom JSON format for blocklists and entitylists. The current blocklist format lacks regex pattern matching and the ability to block only images, scripts, or other specific resources from a page. The Fenix project would like first party support for the industry-standard blocklists used by other ad blockers, so we can benefit from the work of community-updated blocklists with our own custom ad blocking solution.
| C++?
| [https://mozillians.org/en-US/u/colee/ Colin Lee]
| Seeking a mentor
| https://bugzilla.mozilla.org/show_bug.cgi?id=1519197
|-
| [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
|-
| Improve 3rd party deployment experience of [https://pontoon.mozilla.org/sl/ Pontoon]
| [https://pontoon.mozilla.org/sl/ Pontoon] is Mozilla's localization tool, used by hundreds of contributors and critical to shipping Firefox, mozilla.org, and many other Mozilla products to as many users as possible, all around the world.

This year, we would like to improve the experience for third-party installations of Pontoon.
| Django, Python, documentation writing.
| Matjaž Horvat (Mozilla)
| Matjaž Horvat (Mozilla)
| While used internally at Mozilla, Pontoon is a general purpose [https://en.wikipedia.org/wiki/Translation_management_system TMS] with good support for popular localization file formats, ready to localize a variety of open source projects, apps or websites.

Deployment itself is [https://mozilla-pontoon.readthedocs.io/en/latest/admin/deployment.html documented] and straightforward, but the first step that follows (setting up projects for localization) isn't. We've identified some of the post-deployment issues in [https://bugzilla.mozilla.org/show_bug.cgi?id=1497572 bug 1497572]:
* Some high-visibility links are broken until you set up projects for localization.
* [https://mozilla-l10n.github.io/documentation/tools/pontoon/ Docs for setting up projects] are Mozilla-specific and hard to find.
* [https://developer.mozilla.org/en-US/docs/Mozilla/Implementing_Pontoon_in_a_Mozilla_website Docs for making projects localizable] are Mozilla-specific and hard to find.
* Homepage is Mozilla-centric and there's no easy way to customize it.

Your task will be to address these issues and implement other ideas you may have.
|-
| WebSocket Monitor
| The 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 visualization 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.).
| 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]
|
|-
| ..your next idea here!
|
|
|
|
|
|}

Phabricator/TestPlan

2017-11-01T15:32:21Z

Dwalsh: Fix heading for something no longer broken.

== Getting Started ==

The following steps are required to get QA up and running for Phabricator testing on Mozilla's staging server.

1. Clone the following repositories to the same directory on your machine:

* https://github.com/phacility/libphutil
* https://github.com/phacility/arcanist

2. Open your `~/.bash_profile` file and add the following:

alias arc='/Users/youruser/path/to/arcanist/bin/arc'

Doing so will allow you to use the `arc` command from anywhere on your machine

3. Clone the repo(s) you plan to test on:

* Staging: https://hg.mozilla.org/automation/phabricator-qa-stage/
* Dev: https://hg.mozilla.org/automation/phabricator-qa-dev/

3. In the local repository checkout, run:

arc install-certificate

Follow the instructions presented in the command line to associate your local machine with the phabricator instance via an API key.

4. Test away! You can create branches within your local repository checkout, add commits, and send them to Phabricator via `arc diff HEAD^`.

This should be all you need to get going with arc and our staging and dev servers!

== Test Plan ==
These tests will be useful when upgrading Phabricator to newer versions or when
adding new features to the integration to ensure everything works as expected.

* Update this doc with new tests as features are added/changed.
* Use a [FAILING] to denote tests which do not work as expected in the
with the current Phabricator/BMO on production. Ideally link to a bug
with the fix.
* See the end of this doc for instructions on how to setup a local test
environment if that is what you need.

=== Signing up is successful ===

====Test Plan====
* Create a new BMO account.
* Make sure to include an irc nick in the Real Name field.
- E.g. "John Doe [:jdoe]"
* Go to Phabricator and login as the new user.
* Finish account creation.

====Results====
* On the Phabricator Create a New Account page
- Username should be prefilled with the irc nick.
- Real Name is correct and does not contain []
* Clicking register approval completes account creation without error.
- On local test instances you might have to login as the Phabricator admin
and approve the account (see the end of this doc for how).
* The account works as expected.

[EDGE CASE] Currently when you revoke the "MozPhab" API key on BMO, there
is no way to create a new one for Phabricator to use.

=== Creating a revision is successful ===

====Test Plan====
* Make sure you have arc properly setup on your machine and have run
`arc install-certificate` using the Phabricator user you wish to test with.
* Go to BMO and create a new bug as the Bugzilla user that the Phabricator
account is connected to. (Or use an existing public bug).
- To create bugs directly and bypass triaging, go to:
http://bmo.test/enter_bug.cgi?product=Firefox&format=__default__
* Create a new hg repo (see instructions at the bottom).
* Make some change to a file.
* Run `hg commit -A -m 'commit1: New changes`
* Run `arc diff .^`
* Input something for the title, summary, test plan, and the correct bug id.
* Save and exit the file.

====Results====
* arc diff only submitted the 1 newly created commit.
* Visit Phabricator and there should be a new revision with the title.
* The revision should contain the correct diff of the changes that were made
* The "Bugzilla Bug ID" is correct.
- The Bug number is correct.
- The link is correct based on the enviroment (bugzilla.mozilla.org in production,
bmo.test in local testing, etc).
- Note: If the bug id is short (like 3, 92, etc, which is common on local
test environments) the link will not work but that is fine because it only
works on very long bug ids which match what new bugs on production bmo
will be using.
* Visiting the bug on bugzilla shows an x-phabricator-request attachment.

=== Updating a revision is successful ===

====Test Plan====
* `hg update` to a commit which you previously submitted with arc
* Make a change and `hg commit`
- If you make a new commit run `arc diff .^^`
- If you amend the existing commit run `arc diff .^`

====Results====
* arc should automatically detect a revision and ask you if you want to update it.
* The revision is updated with the new diff on Phabricator.
* The bug id and other information remains unchanged.

=== Creating a secure revision is successful ===

====Test Plan====
* Go to bugzilla and create a security bug.
* Create a new hg commit.
* Run `arc diff .^`.
* Enter the title, summary, test plan, and the bug id of the security bug.
* Submit the revision.

====Results====
* The diff and information of the revision are as expected.
* The revision has a "Custom Policy" attached to it.
* The revision added the creator as a subscriber.
* The revision is visible to the user who made it.
* The revision is visible to users belonging to the security groups of the bug.
* The revision is NOT visible to the public without logging in.
* The revision is NOT visible to logged in members without the correct permission.
* There is an x-phabricator-request attachment on the bug in Bugzilla.

=== Creating a revision checks the bug id ===

====Test Plan====
* Create a new hg commit.
* Run `arc diff .^`
* Enter information for the title, summary, and test plan.
* Enter the bug id, repeat for each expected result.

**Result**
* Entering no bug id fails.
* Entering an invalid bug id like "abcd efg", or "$1000", fails.
* Entering the id of a bug that does not exist fails.
* Entering the id of a bug of a secure revision that the user does not have
access to fails.
* Entering a valid bug id is successful.

=== Creating multiple revisions with the same bug id is successful ===

====Test Plan====
* Create a new hg commit.
* Run `arc diff .^`
* Enter information for the title, summary, and test plan.
* Enter the bug id.
* Repeat and create another revision with the same bug id.

**Result**
* Both revisions are created successfully.
* There are 2 corresponding x-phabricator-request attachments on the bug in bugzilla.- Entering no bug id fails.

=== Requesting a reviewer on a revision is successful ===

====Test Plan====
* Ensure that you have 2 phabricator accounts that login via BMO ready to go.
- If not, create a new bugzilla user and the phabricator account for it.
* Create a commit, run arc diff.
* Input the title, summary, test plan, and bug id of a public bug.
* For the reviewers field enter the Phabricator user name of the other account.

====Results====
* The revision is created as normal.
* The phabricator attachment on bugzilla is present.
* Phabricator shows the reviewer on the Revision.

=== Review Status is propagated to Bugzilla ===

This test depends on unfinished changes to BMO.

====Test Plan====
* Login to Phabricator as the Reviewer on a Revision
* Accept the Revision

====Results====
* The attachment on the bug in Bugzilla should have

## How to setup a local test environment
* Install arcanist on your machine: https://secure.phabricator.com/book/phabricator/article/arcanist/#installing-arcanist
* Delete all docker containers and images from a previous instance of this test
environment. Or delete EVERYTHING with:
- `docker rm $(docker ps -a -q)`
- `docker rmi $(docker images -q)`
- `docker volume rm $(docker volume ls)`
* Clone the following repos.
- https://github.com/mozilla-services/phabricator-extensions
- https://github.com/mozilla-conduit/bmo-extensions
- https://github.com/mozilla-conduit/docker-bmo
- We are making a local clone of docker-bmo because it doesn't update the
image on DockerHub unless someone commits something on the master branch.
This could cause situations where changes merged in upstream BMO aren't
reflected in the local image. We are going to build the image ourselves
locally.
* In second to last line (i.e. ~63) of the docker-bmo Dockerfile add:
* `RUN chown -R $BUGZILLA_USER.$BUGZILLA_USER /var/www/html/bmo`
* In the docker-compose file in bmo-extensions replace the bmo.test build:
```yml
build:
context: ../docker-bmo
dockerfile: ./Dockerfile
```
* Follow the instructions at https://github.com/mozilla-conduit/bmo-extensions/blob/master/HACKING.md
- **\*WHILE DOING SO KEEP IN MIND:\***
- Make sure to put an empty {} in the `phabext.json` when you make it.
- If there are any custom changes you want to test in the phabricator-extensions
repo, create a new git branch and merge the changes.
- If there are any custom changes you want to test in for the bmo extensions,
follow the instructions until you get to the point where you can enter inside
the bmo container. At that point, modify the files directly. wget is inside
the container to easily download patch files.
- BMO files are at `/var/www/html/bmo/*`, or something close to that.
- You will need to stop the container and run `docker-compose up` again
to restart it with the new changes.
- You do not need to add the test repo if you use the recommendations below.
- The instructions to "proxy your port to 1090" mean to add a proxy config
in the Firefox browser you are using to test with. Options -> Network Proxy
-> Enter localhost (or ip of the thing running docker), port 1090.
- You might have to run `cd phabricator && ./bin/storage upgrade` inside the
phabricator container after the very first time you start it.
- See the login for Phabricator below for when you have to edit the configuration.
- Don't forget to change the bmo url to `http://bmo.test`
- For the bmo api key you will have to generate one by logging into bmo.test
as the phab-bot@bmo.tld user (one should already be made though).
- Once you've been able to login through bmo auth (preferably with the new
unprevileged bmo account you created [details below]), you will have to
"Approve" it. Login as the Phabricator admin again and go to
http://phabricator.test/people/query/approval/ and approve the new user.
* **[Recommended]** Create a dummy hg repo on bitbucket.org to use for testing.
* **[Recommended]** Setup Phabricator to use that repository. Create a new one
at http://phabricator.test/diffusion/edit/form/default/. Set repo URL to
observe mode.
* **[Recommended]** Add `apk add openssh` in the Phabricator Dockerfile, rebuld.
Then inside the container create a new ssh key, add it to your bitbucket account,
and run hg clone <repo>. Also run `hg config --edit`.
* **[Recommended]** Inside the Phabricator container alias arc with
`alias arc='/app/arcanist/bin/arc'`.
* **[Recommended]**: Login as admin@mozilla.bugs and create a new unprivileged
user at http://bmo.test/editusers.cgi?action=add. Then test with that user.
(Then login to phabricator.test with the new user and re-run
`arc install-certificate` so that arc uses the new user's credentials).
* **[TIP]** Logins that come preinstalled:
- Bugzilla
- User: admin@mozilla.bugs, Password: password
- User: phab-bot@bmo.tld, Password: password
- Phabricator:
- Append a `?admin` to the login URL to show the hidden admin login form.
- User: admin, Password: admin

Please contact a developer within the #conduit IRC channel with further questions.

Phabricator/TestPlan

2017-10-30T18:48:10Z

Dwalsh: Fixed formatting of structure.

== Getting Started ==

The following steps are required to get QA up and running for Phabricator testing on Mozilla's staging server.

1. Clone the following repositories to the same directory on your machine:

* https://github.com/phacility/libphutil
* https://github.com/phacility/arcanist

2. Open your `~/.bash_profile` file and add the following:

alias arc='/Users/youruser/path/to/arcanist/bin/arc'

Doing so will allow you to use the `arc` command from anywhere on your machine

3. Clone the repo(s) you plan to test on:

* Staging: https://hg.mozilla.org/automation/phabricator-qa-stage/
* Dev: https://hg.mozilla.org/automation/phabricator-qa-dev/

3. In the local repository checkout, run:

arc install-certificate

Follow the instructions presented in the command line to associate your local machine with the phabricator instance via an API key.

4. Test away! You can create branches within your local repository checkout, add commits, and send them to Phabricator via `arc diff HEAD^`.

This should be all you need to get going with arc and our staging and dev servers!

== Test Plan ==
These tests will be useful when upgrading Phabricator to newer versions or when
adding new features to the integration to ensure everything works as expected.

* Update this doc with new tests as features are added/changed.
* Use a [FAILING] to denote tests which do not work as expected in the
with the current Phabricator/BMO on production. Ideally link to a bug
with the fix.
* See the end of this doc for instructions on how to setup a local test
environment if that is what you need.

=== Signing up is successful ===

====Test Plan====
* Create a new BMO account.
* Make sure to include an irc nick in the Real Name field.
- E.g. "John Doe [:jdoe]"
* Go to Phabricator and login as the new user.
* Finish account creation.

====Results====
* On the Phabricator Create a New Account page
- Username should be prefilled with the irc nick.
- Real Name is correct and does not contain []
* Clicking register approval completes account creation without error.
- On local test instances you might have to login as the Phabricator admin
and approve the account (see the end of this doc for how).
* The account works as expected.

[EDGE CASE] Currently when you revoke the "MozPhab" API key on BMO, there
is no way to create a new one for Phabricator to use.

=== Creating a revision is successful ===

====Test Plan====
* Make sure you have arc properly setup on your machine and have run
`arc install-certificate` using the Phabricator user you wish to test with.
* Go to BMO and create a new bug as the Bugzilla user that the Phabricator
account is connected to. (Or use an existing public bug).
- To create bugs directly and bypass triaging, go to:
http://bmo.test/enter_bug.cgi?product=Firefox&format=__default__
* Create a new hg repo (see instructions at the bottom).
* Make some change to a file.
* Run `hg commit -A -m 'commit1: New changes`
* Run `arc diff .^`
* Input something for the title, summary, test plan, and the correct bug id.
* Save and exit the file.

====Results====
* arc diff only submitted the 1 newly created commit.
* Visit Phabricator and there should be a new revision with the title.
* The revision should contain the correct diff of the changes that were made
* The "Bugzilla Bug ID" is correct.
- The Bug number is correct.
- The link is correct based on the enviroment (bugzilla.mozilla.org in production,
bmo.test in local testing, etc).
- Note: If the bug id is short (like 3, 92, etc, which is common on local
test environments) the link will not work but that is fine because it only
works on very long bug ids which match what new bugs on production bmo
will be using.
* Visiting the bug on bugzilla shows an x-phabricator-request attachment.

=== Updating a revision is successful ===

====Test Plan====
* `hg update` to a commit which you previously submitted with arc
* Make a change and `hg commit`
- If you make a new commit run `arc diff .^^`
- If you amend the existing commit run `arc diff .^`

====Results====
* arc should automatically detect a revision and ask you if you want to update it.
* The revision is updated with the new diff on Phabricator.
* The bug id and other information remains unchanged.

=== Creating a secure revision is successful ===

====Test Plan====
* Go to bugzilla and create a security bug.
* Create a new hg commit.
* Run `arc diff .^`.
* Enter the title, summary, test plan, and the bug id of the security bug.
* Submit the revision.

====Results====
* The diff and information of the revision are as expected.
* The revision has a "Custom Policy" attached to it.
* The revision added the creator as a subscriber.
* The revision is visible to the user who made it.
* The revision is visible to users belonging to the security groups of the bug.
* The revision is NOT visible to the public without logging in.
* The revision is NOT visible to logged in members without the correct permission.
* There is an x-phabricator-request attachment on the bug in Bugzilla.

=== Creating a revision checks the bug id ===

====Test Plan====
* Create a new hg commit.
* Run `arc diff .^`
* Enter information for the title, summary, and test plan.
* Enter the bug id, repeat for each expected result.

**Result**
* Entering no bug id fails.
* Entering an invalid bug id like "abcd efg", or "$1000", fails.
* Entering the id of a bug that does not exist fails.
* Entering the id of a bug of a secure revision that the user does not have
access to fails.
* Entering a valid bug id is successful.

=== Creating multiple revisions with the same bug id is successful ===

====Test Plan====
* Create a new hg commit.
* Run `arc diff .^`
* Enter information for the title, summary, and test plan.
* Enter the bug id.
* Repeat and create another revision with the same bug id.

**Result**
* Both revisions are created successfully.
* There are 2 corresponding x-phabricator-request attachments on the bug in bugzilla.- Entering no bug id fails.

=== Requesting a reviewer on a revision is successful ===

====Test Plan====
* Ensure that you have 2 phabricator accounts that login via BMO ready to go.
- If not, create a new bugzilla user and the phabricator account for it.
* Create a commit, run arc diff.
* Input the title, summary, test plan, and bug id of a public bug.
* For the reviewers field enter the Phabricator user name of the other account.

====Results====
* The revision is created as normal.
* The phabricator attachment on bugzilla is present.
* Phabricator shows the reviewer on the Revision.

=== BROKEN] [Review Status is propogated to Bugzilla ===

This test depends on unfinished changes to BMO.

====Test Plan====
* Login to Phabricator as the Reviewer on a Revision
* Accept the Revision

====Results====
* The attachment on the bug in Bugzilla should have

## How to setup a local test environment
* Install arcanist on your machine: https://secure.phabricator.com/book/phabricator/article/arcanist/#installing-arcanist
* Delete all docker containers and images from a previous instance of this test
environment. Or delete EVERYTHING with:
- `docker rm $(docker ps -a -q)`
- `docker rmi $(docker images -q)`
- `docker volume rm $(docker volume ls)`
* Clone the following repos.
- https://github.com/mozilla-services/phabricator-extensions
- https://github.com/mozilla-conduit/bmo-extensions
- https://github.com/mozilla-conduit/docker-bmo
- We are making a local clone of docker-bmo because it doesn't update the
image on DockerHub unless someone commits something on the master branch.
This could cause situations where changes merged in upstream BMO aren't
reflected in the local image. We are going to build the image ourselves
locally.
* In second to last line (i.e. ~63) of the docker-bmo Dockerfile add:
* `RUN chown -R $BUGZILLA_USER.$BUGZILLA_USER /var/www/html/bmo`
* In the docker-compose file in bmo-extensions replace the bmo.test build:
```yml
build:
context: ../docker-bmo
dockerfile: ./Dockerfile
```
* Follow the instructions at https://github.com/mozilla-conduit/bmo-extensions/blob/master/HACKING.md
- **\*WHILE DOING SO KEEP IN MIND:\***
- Make sure to put an empty {} in the `phabext.json` when you make it.
- If there are any custom changes you want to test in the phabricator-extensions
repo, create a new git branch and merge the changes.
- If there are any custom changes you want to test in for the bmo extensions,
follow the instructions until you get to the point where you can enter inside
the bmo container. At that point, modify the files directly. wget is inside
the container to easily download patch files.
- BMO files are at `/var/www/html/bmo/*`, or something close to that.
- You will need to stop the container and run `docker-compose up` again
to restart it with the new changes.
- You do not need to add the test repo if you use the recommendations below.
- The instructions to "proxy your port to 1090" mean to add a proxy config
in the Firefox browser you are using to test with. Options -> Network Proxy
-> Enter localhost (or ip of the thing running docker), port 1090.
- You might have to run `cd phabricator && ./bin/storage upgrade` inside the
phabricator container after the very first time you start it.
- See the login for Phabricator below for when you have to edit the configuration.
- Don't forget to change the bmo url to `http://bmo.test`
- For the bmo api key you will have to generate one by logging into bmo.test
as the phab-bot@bmo.tld user (one should already be made though).
- Once you've been able to login through bmo auth (preferably with the new
unprevileged bmo account you created [details below]), you will have to
"Approve" it. Login as the Phabricator admin again and go to
http://phabricator.test/people/query/approval/ and approve the new user.
* **[Recommended]** Create a dummy hg repo on bitbucket.org to use for testing.
* **[Recommended]** Setup Phabricator to use that repository. Create a new one
at http://phabricator.test/diffusion/edit/form/default/. Set repo URL to
observe mode.
* **[Recommended]** Add `apk add openssh` in the Phabricator Dockerfile, rebuld.
Then inside the container create a new ssh key, add it to your bitbucket account,
and run hg clone <repo>. Also run `hg config --edit`.
* **[Recommended]** Inside the Phabricator container alias arc with
`alias arc='/app/arcanist/bin/arc'`.
* **[Recommended]**: Login as admin@mozilla.bugs and create a new unprivileged
user at http://bmo.test/editusers.cgi?action=add. Then test with that user.
(Then login to phabricator.test with the new user and re-run
`arc install-certificate` so that arc uses the new user's credentials).
* **[TIP]** Logins that come preinstalled:
- Bugzilla
- User: admin@mozilla.bugs, Password: password
- User: phab-bot@bmo.tld, Password: password
- Phabricator:
- Append a `?admin` to the login URL to show the hidden admin login form.
- User: admin, Password: admin

Please contact a developer within the #conduit IRC channel with further questions.

Phabricator/TestPlan

2017-10-30T18:45:43Z

Dwalsh: /* Getting Started */

== Getting Started ==

The following steps are required to get QA up and running for Phabricator testing on Mozilla's staging server.

1. Clone the following repositories to the same directory on your machine:

* https://github.com/phacility/libphutil
* https://github.com/phacility/arcanist

2. Open your `~/.bash_profile` file and add the following:

alias arc='/Users/youruser/path/to/arcanist/bin/arc'

Doing so will allow you to use the `arc` command from anywhere on your machine

3. Clone the repo(s) you plan to test on:

* Staging: https://hg.mozilla.org/automation/phabricator-qa-stage/
* Dev: https://hg.mozilla.org/automation/phabricator-qa-dev/

3. In the local repository checkout, run:

arc install-certificate

Follow the instructions presented in the command line to associate your local machine with the phabricator instance via an API key.

4. Test away! You can create branches within your local repository checkout, add commits, and send them to Phabricator via `arc diff HEAD^`.

This should be all you need to get going with arc and our staging and dev servers!

=== Test Plan ===
These tests will be useful when upgrading Phabricator to newer versions or when
adding new features to the integration to ensure everything works as expected.

* Update this doc with new tests as features are added/changed.
* Use a [FAILING] to denote tests which do not work as expected in the
with the current Phabricator/BMO on production. Ideally link to a bug
with the fix.
* See the end of this doc for instructions on how to setup a local test
environment if that is what you need.

=== [Signing up is successful] ===

====Test Plan====
* Create a new BMO account.
* Make sure to include an irc nick in the Real Name field.
- E.g. "John Doe [:jdoe]"
* Go to Phabricator and login as the new user.
* Finish account creation.

====Results====
* On the Phabricator Create a New Account page
- Username should be prefilled with the irc nick.
- Real Name is correct and does not contain []
* Clicking register approval completes account creation without error.
- On local test instances you might have to login as the Phabricator admin
and approve the account (see the end of this doc for how).
* The account works as expected.

[EDGE CASE] Currently when you revoke the "MozPhab" API key on BMO, there
is no way to create a new one for Phabricator to use.

=== [Creating a revision is successful] ===

====Test Plan====
* Make sure you have arc properly setup on your machine and have run
`arc install-certificate` using the Phabricator user you wish to test with.
* Go to BMO and create a new bug as the Bugzilla user that the Phabricator
account is connected to. (Or use an existing public bug).
- To create bugs directly and bypass triaging, go to:
http://bmo.test/enter_bug.cgi?product=Firefox&format=__default__
* Create a new hg repo (see instructions at the bottom).
* Make some change to a file.
* Run `hg commit -A -m 'commit1: New changes`
* Run `arc diff .^`
* Input something for the title, summary, test plan, and the correct bug id.
* Save and exit the file.

====Results====
* arc diff only submitted the 1 newly created commit.
* Visit Phabricator and there should be a new revision with the title.
* The revision should contain the correct diff of the changes that were made
* The "Bugzilla Bug ID" is correct.
- The Bug number is correct.
- The link is correct based on the enviroment (bugzilla.mozilla.org in production,
bmo.test in local testing, etc).
- Note: If the bug id is short (like 3, 92, etc, which is common on local
test environments) the link will not work but that is fine because it only
works on very long bug ids which match what new bugs on production bmo
will be using.
* Visiting the bug on bugzilla shows an x-phabricator-request attachment.

=== [Updating a revision is successful] ===

====Test Plan====
* `hg update` to a commit which you previously submitted with arc
* Make a change and `hg commit`
- If you make a new commit run `arc diff .^^`
- If you amend the existing commit run `arc diff .^`

====Results====
* arc should automatically detect a revision and ask you if you want to update it.
* The revision is updated with the new diff on Phabricator.
* The bug id and other information remains unchanged.

=== [Creating a secure revision is successful] ===

====Test Plan====
* Go to bugzilla and create a security bug.
* Create a new hg commit.
* Run `arc diff .^`.
* Enter the title, summary, test plan, and the bug id of the security bug.
* Submit the revision.

====Results====
* The diff and information of the revision are as expected.
* The revision has a "Custom Policy" attached to it.
* The revision added the creator as a subscriber.
* The revision is visible to the user who made it.
* The revision is visible to users belonging to the security groups of the bug.
* The revision is NOT visible to the public without logging in.
* The revision is NOT visible to logged in members without the correct permission.
* There is an x-phabricator-request attachment on the bug in Bugzilla.

=== [Creating a revision checks the bug id] ===

====Test Plan====
* Create a new hg commit.
* Run `arc diff .^`
* Enter information for the title, summary, and test plan.
* Enter the bug id, repeat for each expected result.

**Result**
* Entering no bug id fails.
* Entering an invalid bug id like "abcd efg", or "$1000", fails.
* Entering the id of a bug that does not exist fails.
* Entering the id of a bug of a secure revision that the user does not have
access to fails.
* Entering a valid bug id is successful.

=== [Creating multiple revisions with the same bug id is successful] ===

====Test Plan====
* Create a new hg commit.
* Run `arc diff .^`
* Enter information for the title, summary, and test plan.
* Enter the bug id.
* Repeat and create another revision with the same bug id.

**Result**
* Both revisions are created successfully.
* There are 2 corresponding x-phabricator-request attachments on the bug in bugzilla.- Entering no bug id fails.

=== [Requesting a reviewer on a revision is successful] ===

====Test Plan====
* Ensure that you have 2 phabricator accounts that login via BMO ready to go.
- If not, create a new bugzilla user and the phabricator account for it.
* Create a commit, run arc diff.
* Input the title, summary, test plan, and bug id of a public bug.
* For the reviewers field enter the Phabricator user name of the other account.

====Results====
* The revision is created as normal.
* The phabricator attachment on bugzilla is present.
* Phabricator shows the reviewer on the Revision.

=== [BROKEN] [Review Status is propogated to Bugzilla] ===

This test depends on unfinished changes to BMO.

====Test Plan====
* Login to Phabricator as the Reviewer on a Revision
* Accept the Revision

====Results====
* The attachment on the bug in Bugzilla should have

## How to setup a local test environment
* Install arcanist on your machine: https://secure.phabricator.com/book/phabricator/article/arcanist/#installing-arcanist
* Delete all docker containers and images from a previous instance of this test
environment. Or delete EVERYTHING with:
- `docker rm $(docker ps -a -q)`
- `docker rmi $(docker images -q)`
- `docker volume rm $(docker volume ls)`
* Clone the following repos.
- https://github.com/mozilla-services/phabricator-extensions
- https://github.com/mozilla-conduit/bmo-extensions
- https://github.com/mozilla-conduit/docker-bmo
- We are making a local clone of docker-bmo because it doesn't update the
image on DockerHub unless someone commits something on the master branch.
This could cause situations where changes merged in upstream BMO aren't
reflected in the local image. We are going to build the image ourselves
locally.
* In second to last line (i.e. ~63) of the docker-bmo Dockerfile add:
* `RUN chown -R $BUGZILLA_USER.$BUGZILLA_USER /var/www/html/bmo`
* In the docker-compose file in bmo-extensions replace the bmo.test build:
```yml
build:
context: ../docker-bmo
dockerfile: ./Dockerfile
```
* Follow the instructions at https://github.com/mozilla-conduit/bmo-extensions/blob/master/HACKING.md
- **\*WHILE DOING SO KEEP IN MIND:\***
- Make sure to put an empty {} in the `phabext.json` when you make it.
- If there are any custom changes you want to test in the phabricator-extensions
repo, create a new git branch and merge the changes.
- If there are any custom changes you want to test in for the bmo extensions,
follow the instructions until you get to the point where you can enter inside
the bmo container. At that point, modify the files directly. wget is inside
the container to easily download patch files.
- BMO files are at `/var/www/html/bmo/*`, or something close to that.
- You will need to stop the container and run `docker-compose up` again
to restart it with the new changes.
- You do not need to add the test repo if you use the recommendations below.
- The instructions to "proxy your port to 1090" mean to add a proxy config
in the Firefox browser you are using to test with. Options -> Network Proxy
-> Enter localhost (or ip of the thing running docker), port 1090.
- You might have to run `cd phabricator && ./bin/storage upgrade` inside the
phabricator container after the very first time you start it.
- See the login for Phabricator below for when you have to edit the configuration.
- Don't forget to change the bmo url to `http://bmo.test`
- For the bmo api key you will have to generate one by logging into bmo.test
as the phab-bot@bmo.tld user (one should already be made though).
- Once you've been able to login through bmo auth (preferably with the new
unprevileged bmo account you created [details below]), you will have to
"Approve" it. Login as the Phabricator admin again and go to
http://phabricator.test/people/query/approval/ and approve the new user.
* **[Recommended]** Create a dummy hg repo on bitbucket.org to use for testing.
* **[Recommended]** Setup Phabricator to use that repository. Create a new one
at http://phabricator.test/diffusion/edit/form/default/. Set repo URL to
observe mode.
* **[Recommended]** Add `apk add openssh` in the Phabricator Dockerfile, rebuld.
Then inside the container create a new ssh key, add it to your bitbucket account,
and run hg clone <repo>. Also run `hg config --edit`.
* **[Recommended]** Inside the Phabricator container alias arc with
`alias arc='/app/arcanist/bin/arc'`.
* **[Recommended]**: Login as admin@mozilla.bugs and create a new unprivileged
user at http://bmo.test/editusers.cgi?action=add. Then test with that user.
(Then login to phabricator.test with the new user and re-run
`arc install-certificate` so that arc uses the new user's credentials).
* **[TIP]** Logins that come preinstalled:
- Bugzilla
- User: admin@mozilla.bugs, Password: password
- User: phab-bot@bmo.tld, Password: password
- Phabricator:
- Append a `?admin` to the login URL to show the hidden admin login form.
- User: admin, Password: admin

Please contact a developer within the #conduit IRC channel with further questions.

Phabricator/TestPlan

2017-10-30T18:30:19Z

Dwalsh: /* Getting Started */

Phabricator/TestPlan

2017-10-30T18:25:31Z

Dwalsh: Created page with "== Getting Started == The following steps are required to get QA up and running for Phabricator testing on Mozilla's staging server. 1. Clone the following repositories to..."

MDN/Development/Redesign/NewDesignV1

2013-09-05T16:49:31Z

Dwalsh: /* Comments from Will */

Here is the link to v1. of the proposed design:
*[https://wiki.mozilla.org/images/d/dd/Mdn-redesign_v1.pdf '''Proposed MDN Design - new''']

=Comments=
Please enter feedback here. Specifically, any issues with l10n, readability, etc.

* Is this the "app center" that dbuchner talks about? [[User:Markg|Markg]] ([[User talk:Markg|talk]]) 11:51, 14 August 2013 (PDT)
* I think it looks very nice in general. But I can't tell how good a lot of it is because it does not use actual content from MDN so that I can compare it to something real. For example, I can't tell what the gray box at the top of the center column of text is supposed to be. Is this gray box meant to call out a quick summary of the page? If so it should have some content that would show it or explain it ("This gray box holds a summary of what is on this page." etc.) Are the quick links supposed to relate to what is in the center column of this page, or are they going to be general for the whole site? The ones that are there don't make any sense to me and so I can't tell how effective having "quick links" might be. If they related to some real content in the center column it would be easier for me to evaluate the design. What is a "navigation pattern"? I haven't heard this term. I like having the review checkboxes at the top of the page.
* How will some of the wider MDN tables look in this design? Like on this page: [https://developer.mozilla.org/en-US/docs/Web/Apps/App_permissions App permissions]
*This is completely superficial, but can we have the Mozilla "dragon" logo (like in the bottom left of this page) in the corner? I see the MDN title has "For placement only" beside it, does that mean the dragon might make a reappearance?

=== Comment from [[User:Jeremie|Jeremie]], 16 August 2013 ===

Here a few things that I think needs improvement:

==== landing Page ====

* The blue header is very nice but a bit wider. It take a lot of space therefor the fold come very quickly and the page show off very few useful content. Maybe with a larger title it does not feel that way, but this header could be soften a little by shrink the space available before and after the main title ("Apps")
* Aside point, the white paragraph at the bottom of the header is not properly align with the grey column on the left. There again, it could be possible to shrink the blue space below the paragraph to soften the header a bit more.
* The editing tools are completely hidden and barely undiscoverable. I guess it's on purpose on that kind of page, however I suggest to switch the background color and the font color of that button. That way they remain unadvertised but slightly more discoverable (remind that those button should be display to login users only).
* I'm missing a few things:
** How the login zone looks like (and where it is positioned)?
** On the column on the left, how the items on white background looks like when they are open? (for example, how the inner white arrows of the items on the grey background is handled?)
** About l10N: How does the page looks when an item (title, links, button) has its text displayed on 2 lines?

==== Content Page ====

* The all grey and blue approach make everything very flat. It's pretty hard to figure how it will behave with real content. Currently I think there isn't enough contrast between the main content and the aside contents making all of this a bit blurry.
* The titles ("Navigation patterns")
** How does it looks when displayed on two lines?
** IMO, The arrows navigation pattern looks very odd on a wiki. I have difficulty to see how we will be able to define what is next/previous page.
* The right column ("quicklinks"):
** The right align is very bad, it makes difficult to read and counter intuitive for users. It also add some unnecessary complexity for rtl languages vs ltr languages. It also behaves/looks very weirdly when the review box is visible.
** The down arrows on the right of some items suggest it is possible to open it. Is it possible to see an open item?
** The "hide quicklink" button is out of the design grid. Why haven't it align to the "In this article" on the left? It will make things more balanced and allow to shrink the height of the title in order to display useful content faster.
** The position of the review box does not feel right, what is as to do with "quicklinks"?
** Why the review box does not have a validation button? (note that assuming javascript for form validation is a bad practice in web design)
* The left column
** Would it be possible to see the TOC with some 4 level headings (we currently allow that on MDN)
** It would be better to flip tags and attachement links, as tags can be a long list of expression where attachement is just a single line link.
** How very long tags are handled? (meaning, tags that are wider than the column width)
** How tags are displayed when they are on more than one line?
** The way the left column is folded is very odd because it breaks the layout (the first paragraph of the content jump under the "In this article" box). Maybe hiding it on the left rather than on top would be better.
* The main content
** What is the purpose of the first grey box? We have a bunch of content starting with a heading, how is it handled?
** Would it be possible to constrain the width of the content when one or both aside columns are hidden? Accessibility principle define with WCAG state that a [http://www.w3.org/TR/WCAG20/#visual-audio-contrast-visual-presentation text content width should be constrain in a way text lines are 80 characters long] at worst.

==== Both ====

* Is the design responsive? (basically, how it behaves when shrinked or expended in width?) I would love to see this design declined for 1024px, 1200px and 1600px wide screens (and it would be very nice to have a 768px and 480px wide version as well). In today web design, this need to be seriously thought. Note that if design break points are thought based on the content rather than on screen size, it will make potential l10n issues less problematic.
* There is no footer, is it on purpose?
* The search box is really narrow which means that when typing more than two words, the user will not see his full search query (and it will be worst with languages with large words or expression such as German).

===Comments from Will===
* agreed that it would be easier to comment on with real content.

* the articles look very nice, easy to read, clean layout. But how will I fit pages like this (https://developer.mozilla.org/en-US/docs/Tools/Debugger) in such a narrow column? ''I've implemented a max-width of 100% on images so they don't bleed through like that. - DW''

* I'm worried that the "landing page" pages aren't very content-rich. I want a devtools landing page to include a screenshot of the devtools and a short overview of what's in there and what it's all for. To me the most useful bit of the sample page is the stuff under "Topics" but that only starts 2/3 of the way down the page and I probably have to scroll to see it. Sub-parts of this:
** I think the blue band is too tall.
** I'm not very comfortable with "Top Articles" for a couple of reasons: they are often not maintained, and you don't know what I'm doing, so you're unlikely to be able to make good guesses about what I'm looking for
** I'd move "MDN Community" to the bottom.
** I think it's deeply strange to have a heading called "Documentation" alongside "Tools for Developers" and "Technology Reference". It's all documentation, isn't it?

==Notes==
*The set of arrows around the title are intended to be used for navigating between multi-page articles or sets of articles & won't be used on everything...

Engagement/Developer Engagement/2013-08-offsite/travel

2013-07-09T15:57:10Z

Dwalsh: /* Travel info for hotel booking */

=Developer Program August 2013 Offsite=

==Location & Dates==

* Mozilla Toronto Office
* Hotel: Hilton Garden Inn (booked centrally)
* Start: Monday, August 19, 9am
* End: Thursday evening, August 23rd

==Travel info for hotel booking==

Your name in the following table is considered an RSVP.

* Hotel: Please add at least your name, arrival date and departure by Thursday, July 11, 2013 so we can book the hotel rooms.
* Airfare: Please book through Egencia.

{| border="1"
| Name || Arrival, Flight, Date & Time || Departure, Flight Date & Time || Need a hotel room? || Dietary restrictions
|-
| your-name-here || your-arrival || your-departure || yes/no || yes-with-detail-or-no
|-
| David Walsh || TDB || TBD || Yes || No
|-
|}

Engagement/Developer Engagement/2013-08-offsite/travel

2013-07-09T15:56:48Z

Dwalsh: /* Travel info for hotel booking */

Engagement/Developer Engagement/2013-08-offsite/travel

2013-07-09T15:56:33Z

Dwalsh: /* Travel info for hotel booking */

MDN/Projects/Completed/Redesign

2012-09-20T20:42:54Z

Dwalsh: /* Redesign Goals */

Now that we've got kuma launched, it's time to start thinking about the next steps for improving MDN. We'll be kicking off a project to redesign the site and achieve some high-level goals.

== Redesign Goals ==
*Improve performance
*Better site structure, navigation & ability to quickly find key content
*Increased emphasis on search
*Clearer separation of product and Open Web Content
*Update the design to something dynamic, modern, & more consistent with the brand
*Improve user experience & usability
*Improve SEO
*More flexibility in how content is presented (especially the home page & landing pages)

== Redesign Ideas ==
This is just a rough collection of things that we might want to consider when we start the MDN redesign. This is by no means a final list, and by no means well organized. Just a collection of ideas.

*Clean up CSS, JS, and templates
*JavaScript framework update (possibly move to something modular).
*Provide a property list, improved compatibility tables (by browser as well as by element) – similar to W3Schools concept
*Enable mobile/responsive design & printable pages
*Easier to find profiles/listings/ general information
*Better/clearer language selectors & navigation through translated pages
*Refresh demo section & integrate better with rest of content
*Sidebars in given parts of the site: if you're in the CSS reference, you have a sidebar of links to all the CSS properties; if you're in the HTML reference, a sidebar listing the elements.
*Remove discussions from the menu
*Ability to build high level structure & page order natively (w/o resorting to templates)
*Homepage should have a big search box in the middle
*Links to popular topics or a popular doc panel
*Autocomplete will show "canvas" and "css" at the top instead of just autocomplete), so it will still be easy to get to those popular pages from the search box.
*Better navigation within topics and subtopics. Provide clear navigation; if you hit almost any CSS page, for example, you get information about the given topic but it's not always clear where to go next. Or what pages would be related.
*Something like XBreadcrumbs (http://www.ajaxblender.com/script-sources/xbreadcrumbs/demo/index.html)
*Add "favorites". If a user is logged in, we can allow them to "favorite" documents within MDN (not bookmark in the browser) & access via a secondary computer or a mobile device.
*More guided documentation
*Refreshed & more flexible home page; able accommodate new products & technologies
*We might want to take a look at what editors are trying to accomplish with templates, and look at supporting those things natively. Firefox sometimes does the same thing, pulling in features that started out as extensions and gained popularity (bookmark sync, highlighting the domain in the address bar, etc.).
* When a user reaches a page that hasn't been translated yet, they get a message explaining the situation and asking them to help with localization. But this message itself needs to be localized, defeating the purpose [https://developer.mozilla.org/ca/docs/HTML/HTML5 in some cases].
* Localizers should be warned (or better yet, prevented) from localizing variable names. Doing so can cause an internal server error.
* The link between the Demo Studio and the Dev Derby is not especially obvious. Some people (even some people in Engagement) don't realize that they are complementary sister sites.
* It would be great to keep the long contest descriptions around even after the contest has ended. I spend a lot of time on these, and they usually provide pretty good guidance in getting started with the technology.
* have a "Help" link on the MDN, with a few options: I want to report an issue with documentation, I want to report an issue with the underlying software, I want to report an issue with Firefox. In the latter case, we could just bump people over to SUMO, saving us frustration and helping those users get the help they need more quickly.

== Some features that could use thoughts from the user experience team ==
* https://bugzilla.mozilla.org/show_bug.cgi?id=773054
* https://bugzilla.mozilla.org/show_bug.cgi?id=770965#c3
* https://bugzilla.mozilla.org/show_bug.cgi?id=773502
* https://bugzilla.mozilla.org/show_bug.cgi?id=780224
* https://bugzilla.mozilla.org/show_bug.cgi?id=770739
* https://bugzilla.mozilla.org/show_bug.cgi?id=784564
* https://bugzilla.mozilla.org/show_bug.cgi?id=784719
* https://bugzilla.mozilla.org/show_bug.cgi?id=784758
* https://bugzilla.mozilla.org/show_bug.cgi?id=791842

Releases/Firefox/Channels/Beta/FAQ/

2012-09-17T17:55:37Z

Dwalsh: /* Firefox Beta FAQ */

= '''Firefox Beta FAQ''' =

Updated 5.19.11

 

Q: What’s new in Firefox Beta for Windows, Mac and Linux? 

A: This release includes the Firefox channel switcher, performance and stability enhancements and support for the new [https://developer.mozilla.org/en/CSS/CSS_animations CSS Animations standard] to allow developers build more amazing Web experiences. Full details are available in the [http://www.mozilla.com/firefox/5.0beta/releasenotes/ release notes].

 

Q: What’s new in Firefox Beta for Android? 

A: Firefox for Android is the first mobile Web browser to offer the Do Not Track privacy feature. This release also includes performance enhancements that make page load time faster (especially on 3G networks) and improves panning for faster scanning of websites. Full details are available in the [http://www.mozilla.com/mobile/5.0b1/releasenotes/ release notes]. For more info see the [https://www.mozilla.com/mobile/faq mobile FAQ]. 

 

Q: How does Do Not Track work? 

A: Do Not Track lets users tell websites they want to opt-out of online behavioral tracking. To turn Do Not Track on, simply go to the Preferences option in the Firefox Menu (or Preferences option in Browser Tools on Firefox for Android) and check the box next to “tell websites I do not want to be tracked.”

When this option is selected, a HTTP header will be sent signaling to websites that you wish to opt-out of online behavioral tracking. You will not notice any difference in your browsing experience until sites and advertisers start responding to the header. Visit the [http://dnt.mozilla.org/ Mozilla Do Not Track site] for more info.

 

Q: How does the Firefox Channel switcher work (for Windows, Mac and Linux)? 

A: The new [https://blog.mozilla.org/channels/2011/06/02/update-on-channel-switcher/ Firefox channel switcher] lets you move between Firefox Aurora, Beta and Release channels to test features at various levels of development, quality and polish. You can switch between Firefox channels by simply choosing “About” from the Firefox Menu, clicking “Change” and using the drop down menu to select the desired channel (nightly, Aurora, Beta, Release).

Visit this support article for help with the channel switcher. Please [https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&format=guided file any bugs with the channel switcher in Bugzilla], or, by clicking on the Help Menu to submit feedback.

 

Q: Why does Firefox ask for my location? What is Location-Aware Browsing? 

A: Location-Aware Browsing saves you time by allowing websites to ask you where you are. If you choose to share your location with a website, it can use that information to find nearby points of interest and return additional, useful data like maps of your area. It’s all optional – Firefox doesn’t share your location without your permission. Learn more about Location-Aware Browsing and view the privacy policy from the Google Location Service.

 

Q: When will the next version of Firefox be final? 

A: As part of the new rapid release cycle we plan to deliver a final release of the next version of Firefox the week of June 21, 2011.

 

'''Firefox Rapid Releases ''' 

Q: Why switch to a rapid release cycle for Firefox? 

A: Rapid releases let us deliver new features, performance enhancements, security updates and stability improvements to users faster.

 

Q: How does the rapid release cycle work? What is the rapid release timing? 

A: We now have four [http://www.mozilla.com/firefox/channel/ Firefox channels]: nightly, aurora, beta and release. Each stage of the development process lasts for six weeks. 

*Nightly - Test builds including unpolished features not tested by Mozilla QA
*Aurora - Test the latest features and innovations with an increase in polish from the raw, cutting edge features in nightly builds
*Firefox Beta - Broadly test the stability of new features and improvements in the next version of Firefox
*Firefox Release - Delivers the polished and stable features in Firefox to hundreds of millions of users 

 

Q: Why is the new rapid release schedule shorter/different for Firefox 5?

A: Firefox 5 will be slightly different from future releases due to the development overlap with Firefox 4 and the work we’ve done to move to a rapid release cycle. To break down the timeline, this means: rather than six weeks for mozilla-central, mozilla-aurora, and mozilla-beta we instead have three weeks for development on mozilla-central, five weeks to converge and stabilize on mozilla-aurora, and five weeks to validate on mozilla-beta.

 

Q: Is rapid release happening for Firefox for desktop and mobile?

A: Yes!

 

Q: Is there an aurora channel for mobile?

A: Not right now. We recently added a beta channel to Firefox for Android to get more feedback from users and prepare for rapid releases. The beta channel is in addition to the existing nightly test builds and final release channel of Firefox for mobile. There may be an aurora channel soon- stay tuned!

 

Q: Can I switch between Firefox channels? How? A: The new [https://developer.mozilla.org/devnews/index.php/2011/05/04/beta-channel-switcher-testing/ Firefox channel switcher] lets you move between Firefox Aurora, Beta and Release channels to test features at various levels of development, quality and polish. You can switch between Firefox channels by simply choosing “About” from the Firefox Menu, clicking “Change” and using the drop down menu to select the desired channel (nightly, Aurora, Beta, Release).

Visit this support article for help with the channel switcher. Please [https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&format=guided file any bugs with the channel switcher in Bugzilla], or, by clicking on the Help Menu to submit feedback.