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.

Trello notes
Two boards
 * Flow current iteration
 * Every bug and story the engineers should get done in the current two-week "sprint". ''We'll start this January 27, not for the "Thrillhouse" iteration January 13 - 24.


 * Flow backlog
 * Everything that isn't story to get done in the next two weeks:
 * Design work (purple tag) for the next iteration
 * Stories we're refining for future iterations
 * Business analysis and community liaison work
 * The backlog of all good ideas and maybe-someday

So "backlog" also means "readiness", "prep", etc. Better names welcome.

Highest priority at the top. Also cards can have due dates.

More details

 * All design issues should be wrapped up before the next iteration, so their due date is the Tuesday before the iteration starts, so engineers can estimate at the Wednesday poker meeting.
 * want designers to be working two iterations out,
 * When cards move to Flow current iteration board, the designer remains on the card.

If during the current iteration an engineer need something from design, talk on IRC, and:
 * add the purple "Design" label by clicking '''Edit labels...' near the top-ri
 * if a designer isn't associated with the card, click Add members... and add maygalloway to the card.
 * Under Activity, enter @username I need XYZ to create a mention.
 * If you can't get any further, move the card into the BLOCKED column.

Ready for code review
It's unclear if we need an "Awaiting final code review: column. If other engineers ask for changes in "Final code review" then the story has to move back to "in development", so why have the work. Maybe move to BLOCKED and use a sticker, or label it blue for engineering?

Bugs in Trello

 * We'll switch to reviewing bugs in bugzilla, and only pull bugs in when design is going to work on them or when engineers start fixing them.
 * Can apply "design" keyword in bugzilla to note a bug that will take design.
 * TODO Need an easy way to create Trello cards from a named set of bugs, probably an addition to Bugello

Mingle notes

 * We're very likely to move away from Mingle by February 2014


 * 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 rvm, then Ruby, gem, and bundle manager.
 * on you local wiki, add 'Talk:Flow QA' to  ; optionally you can create an account the "Selenium_user" so you don't get all its Echo spam.

Then to run the tests,

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

Other resources

 * E2 (Flow) calendar resource: In Google Calendar, add  to Other calendars, see Calendars page on office wiki for help.