Collaboration/Team/Processes

We're an agile team.

Project
We plan iterations in our Mingle instance, https://mingle.corp.wikimedia.org/projects/flow/

Engineers should try to work right-to-left – highest priority is Awaiting Final Code Review, not your own work In Development.

Master is continually released to en-beta
Everything we merge to Flow master is deployed on en-beta within hours, and then cloudbees runs our simple browser tests against it. So merged commits shouldn't break.
 * Rebase against latest master and verify it works locally before you move a card to "Awaiting final code review"

This means any problem in master should probably be noted in bugzilla, because it's externally visible on en-beta and probably ee-flow as well.

Flow releases to production
As early as December 4, we will enable Flow on mediawiki.org, a production wiki. After this "Devployment" Flow will be on the release train, so that whatever we have checked in to master early Thursday will be deployed to mediawiki.org that day, and then a week later show up on enwiki.


 * Any patches requiring DB updates should be flagged.
 * do they need to be in DB review?

Some time in December we will enable Flow on four WikiProject talk pages on enwiki. Note that mw.org and enwiki will be running different releases yet talking to the same Flow DB and external store, so all DB updates must support later and older code.

Mingle notes

 * The default (blank) epic story is Flow, in Mingle views scroll down to see others.
 * we also track any planned work on Echo in a separate epic story.
 * Engineers must keep the Mingle card state up-to-date
 * If you're working on a bug or story, set yourself as the owner (this happens automatically when you move a card to "In Development" or click one of the buttons in a card review.
 * If you need stuff from design to complete a story, then
 * move it back into "In Design"
 * be clear about what need from design – change the title or mention something in the card.

Gerrit notes

 * Use comments to be clear in what you want. "I want bernie to review the data change before I'm comfortable +2ing"
 * +1 means "OK to merge but I want someone else to take a look"
 * two +1s means it's good enough to merge. The second +1 on a patch should either +2 it or explain why not in comment.
 * Gerrit forgets +1s when someone submits a new patch set, so whoever does so should summarize the state, e.g. "mlitn +1'd patch 5 and this addresses his concerns, so need one more approval."

Code hygiene

 * Jenkins jobs check for jshint failures
 * ToDo: get Jenkins job to run our minimal PHP tests
 * we could enable php codesniffer ( phpcs --standard=path/to/codesniffer/MediaWiki . ), but lots of warnings
 * should enable LESS syntax test
 * ToDo: everyone commit their git commit hooks, local test scripts, Makefile, etc. to extensions/Flow/tests/scripts

Test
Here's what we test when we make a big change ToDo should have a Makefile make update that we run on ee-flow and ee-flow-extra.
 * ToDo

Browser testing
It's not hard to run Flow's tests/browser, see Quality Assurance/Browser testing/Running tests In a nutshell: It's a role in MediaWiki-Vagrant, or install Ruby, gem, and bundle manager.

A big risk of a change is it degrades user experience on one of many browsers none of us use. To try Flow out on alternate browsers, see Browser testing and design tools on officewiki.

Refactoring

 * If it feels more scope than a bug fix, make a card for it, ask spage to add to the iteration.
 * Engineers need to campaign for their ideas – bring up major code changes in the "daily" standup, referring to the story card