Collaboration/Team/Processes

We're an agile team. We come up with processes that work to deliver software, donning suits as required.

Project

 * Our deliverable is simple, but big: Extension:Flow.
 * Incorporating Flow into MediaWiki often requires changes to core (BTW "MediaWiki core" is not the same as "Core Features" team"), so we also make changes there
 * configuration of the extension for WMF wikis is in, just like other extensions
 * Flow introduces a new iteration of the Agora visual design, but for sanity and velocity ☺, we leave updating this in core to other engineers.

Mingle
We plan iterations in our Mingle instance, https://wikimedia.mingle.thoughtworks.com/projects/flow/ (migrated in January 2014 from an office IT server)

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

Review means release!
When you +2 a change to Flow in gerrit, Jenkins will merge it to master. It's now on the release train to appear in front of users!
 * It will appear on beta-labs shortly.
 * It will appear on mediawiki.org next Thursday per the (Deployments calendar)

Meanwhile... Our team, especially our Product Manager who is the sole person who can "Accept" a story, tests new features on our labs test instance ee-flow. So when you +2 any Flow change in gerrit, you must do some housekeeping:
 * update ee-flow to master: in your work Flow directory, make ee-flow, or if you're already on ee-flow cd /srv/mediawiki/extensions/Flow && make master
 * drag the Mingle card for the change into "In Testing"

Master has to work
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 must not break.
 * You should rebase against latest master and verify it works locally before you move a card to "Awaiting final code review"

Any problems you encounter with master should be noted in bugzilla, because it's externally visible on en-beta and probably ee-flow as well.

Flow releases to production
On 2013-12-11 we enabled Flow on mediawiki.org, a production wiki. So whatever is in master as of Thursday morning PST will be deployed to mediawiki.org around noon Thursday.


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

Some time in January we will enable Flow on four WikiProject talk pages on enwiki, so that whatever is deployed to mediawiki.org will show up a week later 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

 * Your commit message must have a line about testing. What unit test or browser test exercises the feature, or why there's no test.
 * 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

 * The Jenkins jobs for the extension checks 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

Test
Here's what we test when we make a big change
 * ToDo
 * ToDo should have the make master command run all our tests.  MobileFrontend runs tests on every git commit,
 * In Retrospectives engineers broadly agree we should write more tests, and when fixing bugs should write tests that fail without the code that fixes the problem. But these are just Good intentions...

Browser testing
It's not hard to run Flow's , 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