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 we should capture these things and post them to the mobile-l@lists.wikimedia.org list (or the reading-wmf@wikimedia.org list for administrivia, standup status if missed standup, or internal confidential topics) to ensure everyone stays in the loop.
 * If something has permanence, put it on the appropriate wiki project page, with rationale and links to previous discussion if appropriate, and follow up on email.
 * When a private email is sent to team members it'll be evaluated if it concerns the whole team and be forwarded to the team's mailing list if appropriate.

Standup

 * 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.

Communication
This is particularly crucial with non-face-to-face communication, as tone becomes even more difficult to decipher.
 * The way we communicate with one another is critical, and has very big impacts on the health of the team. Remember that everyone has their own communication style and ways of thinking about things. As a result, be careful about taking things too personally or reading too deeply into someone's comments.
 * If there is ambiguity in someone's tone, or if it is putting you on the defensive, or making you feel any sort of discomfort, politely and explicitly share that with the person to whom you are speaking.
 * Always approach conversations by giving the other person the benefit of doubt, and with the same honesty, humility, respect, and trust that you expect (or desire) from them.

Rule of 3
The 'Rule of 3': If there is a meeting happening that concerns more than one discipline, if decisions are being made, make sure that there is at least one representative from engineering, design, and product.

This helps ensure that three disciplines are represented in any decision making process, and are more likely to stay on the same page.

Working practices

 * If your laptop is on and you are working, you should be on IRC. This gives all team members, particularly remote ones, the ability to get in touch with you quickly in the event you are needed for something urgent.

Workflow practices

 * Projects tackled by the team must be documented on a wiki page in the Reading Web Projects page before it can be scheduled.
 * If a card in ready for sign off meets the acceptance criteria but has problem, it should be moved to 'accepted' and bugs filed for any issues. If card does NOT meet acceptance criteria, it is moved back to 'ready for development'. (per Retrospective_2014-01-21)
 * Ensure that when fixing regressions there will be tests submitted with the fix.

Code review

 * Patches submitted to the MobileFrontend extension should be reviewed (or at least triaged) within 48 hours.

Working with others

 * We ask that task descriptions in sprint are not edited without sign off from the team (unless they clarify existing points).
 * Any task in sprint changed will be pushed back to in analysis or taken out of the sprint.
 * We strive to share our code as libraries (npm/composer packages), upstream code to core when it makes sense, and group functionality in specific Mediawiki extensions to keep our code focused and properly organized (No monoliths).
 * We will only implement tasks that have clear design specifications before getting into the sprint.
 * Teams needing our help should sync with the tech lead two weeks before they need a change, so we can coordinate the time to help and set expectations.