Readers/Web/Team/Team norms

This page is intended to document norms adopted by the team.


 * If it didn't happen on the mailing list, then it never really happened.
 * In other words, all decisions or things of substance must find their way onto the team's mailing list. Since we're juggling communication between three+ different teams, and many folks are remote, it's difficult to ensure that changes and decisions are communicated effectively - particularly when requirements/designs/etc change. It is not enough for these things to be communicated and known between two people (even if they appear to be the only two people working on something), as other folks may wind up continuing with the same work, or there may be implications to the changes that are only known to someone else on one of the teams. This is not to say that hallway conversations, IRC, etc are not acceptable venues for discussions and decisions, it's just that I believe we should capture these things and post them to mobile-tech@ to ensure everyone stays in the loop.
 * If you are an engineer and you miss standup, send an email to the team with your answers to the standup questions and any other news you may have to share.
 * We reserve the right to chastise and humiliate you for being tardy or missing standups, particularly repeatedly.

Commit summary guidelines for MobileFrontend

 * Follow https://www.mediawiki.org/wiki/Git/Commit_message_guidelines
 * Don't forget to state bug and/or Mingle card number. If posible - in the first line. - what syntax? story #123, (bug 113)? at the beginning?
 * Don't forget to add the target MF version in your commit (eg 'alpha', 'beta','stable')
 * If the commit depends on another commit to external repository (such as MediaWiki core) in a way relevant to WMF deployment, state it clearly and in full detail in commit message and mark the commit with -2 to prevent accidental premature merges. If you don't have +2, ask on IRC. The merging person will be responsible for making sure that all the dependencies have been deployed to the cluster.
 * Add change id of commit so it can be located - place in brackets in commit boy
 * If it is not obvious how to test your commit (eg you have to do magic things to your set up in order to test), explain it in the commit message.

Commit summary syntax (in discussion)
For bugfixes:

(bug XYZ) Do something and everything works [stable/beta/alpha]

Optional detailed info

Dependencies: Optional external dependencies (sha1 or gerrit change ids for commits)

For stories/tasks:

(card #XYZ) Add feature X [stable/beta/alpha]

Optional detailed info Optional external dependencies

I suggest either "card" or "mingle" so that we don't have to check if something is a story or a task just before we commit.
 * I suggest we preface it with 'mingle' - that way it's clear (particulalry to people not on our team) what the number is referring to; so '(mingle #345) Added feature blah [beta]'

As for dependencies, I suggest the convention be to place them after an empty line and provide the header 'dependencies' so it is clearly and quickly identififiable. Eg: (Mingle #345) Add blahblahblah [beta]

Here's some detailed info about what this does, what it's trying to solve, and how you might consider testing it.

Depencies: